Bad Questions

---

پرسش‌های بد

پرسش‌های نامناسب

موقعی که اشخاص برای حل یک مشکل، جهت مشورت یا کمک به دیگران رجوع می‌کنند، اغلب متوجه می‌شوند برای حصول پاسخی که در جستجوی آن هستند، با دشواری مواجه می‌باشند. ^{زیرنویس 1}

تقریباً در تمام موارد، علت این موضوع پرسش نامناسب است. پرسش‌های بد برای هیچکس سودی ندارند. وقت شما را هدر می‌دهند، و به معنی آن است که به احتمال بسیار، اشخاص کمک کردن به شما را حتی امتحان نخواهند نمود.

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

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

گم شده در جزئیات

• من احتیاج دارم، پس از اینکه کلمه‌ای را در یک فایل grep می‌کنم، آن سطر و 4 سطر بعد را حذف کنم. نظری هست؟

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

شخص پرسش کننده سؤال، به هر علت، به اندازه‌ای روی grep متمرکز شده است که این برنامه قسمتی از پرسش گردیده. این مطلب او را نسبت به سایر امکاناتی که grep را فرا نمی‌گیرند، نابینامی‌کند.

برای بدست آوردن پاسخ صحیح، این پرسش را چگونه مجدداً تنظیم نماییم؟

• می‌خواهم یک کلمه را در فایلی پیدا کنم، وسپس آن سطر و چهار سطر بعدی را از فایل حذف نمایم.

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

کمک کنید راه‌حل خود برای مشکلم را تصحیح کنم

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

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

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

10:24|   Milos | یکی می‌تواند نمونه خوبی به من معرفی کند که برای encode کردن چیزی به کار ببرم و قادر به decode کردن آن هم باشد؟ یعنی ‎رمزنگاری و رمزگشایی دوطرفه‎؟
10:24| lhunath | ‏coding یا crypting؟
10:24| lhunath | شاید openssl‏.
10:25|   Milos | اوه، خوب نه lhunath، فکر می‌کنم اشتباه بیان کردم - من درست چیزی می‌خواهم که بتوانم  ‎"hello this has spaces and *2384"‎ به چیزی مانند ‎0938reksfoiur9owe8gi‎ تبدیل کنم، اما قادر به decode کردن آن به طور برعکس نیز باشم.
10:25| lhunath | مقصود؟
10:25|   Milos | ‏lhunath برای عبور دادن شناسه‌هایی که ممکن است شامل فاصله‌ها یا کاراکترهای خاص باشند.

مشکل اصلی به استفاده از پارامترهای bash برای عبور دادن داده‌ها به سایر برنامه‌ها مربوط می‌گردد. راه حل واقعی، نقل‌قولی کردن پارامترها به طور صحیح، هنگامی که به عنوان شناسه‌ها به کار می‌روند یا روش امن دیگری برای عبور دادن داده‌ها، بود. Encoding شناسه داده‌ای به چیزی دیگر، روش ترسناک اجتناب از تفکیک کلمه bash (به جای خاموش کردن آن با نقل‌قولی کردن) می‌باشد و در این حالت، شخص داده‌ها را به درون یک تفسیر کننده کدِ ‌دیگر تزریق می‌کرد. تزریق داده‌ها در کُد، همواره یک ایده واقعاً نامناسب می‌باشد.

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

پرسش‌های محتوی خطاها

<I440r> چگونه می‌توانم PROMPT_COMMAND را در ‎/etc/bashrc‎ طوری ویرایش کنم که نمایش PWD را کوتاه نکند؟

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

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

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

کاربرد مثال ما

• به طور پیش‌فرض فایل ‎/etc/bashrc‎ وجود ندارد. اگر فروشنده سیستم‌عامل شما آن را فراهم نموده است، این بدان معنی است که آنها نگارش Bash در سیستم خودشان را دستکاری کرده‌اند. برخی فروشندگان چنین می‌کنند، اما شما نباید از گرایش آنها پیروی کنید. اگر اتفاقاً یک فایل /etc/bashrc پیدا کردید، قطعاً به این فایل (یا فایل ‎/etc/bash.bashrc‎ -- که گاهی اوقات استفاده می‌شود)نباید چیزی اضافه کنید. در حقیقت، اگر موردی داخل یک فایل ‎/etc/bashrc‎ هست که باعث رنجش شما می‌گردد، تنها آن را حذف نمایید!

• مسئله بزرگتر با فایل ‎/etc/bashrc‎ یا فایلهایی مشابه آن این است که بعضی اشخاص معتقدند که می‌دانند برای کاربرانشان چه چیزی بهتر است، و می‌خواهند محیط کاربرانشان را کنترل کنند. از طرف دیگر، Unix اعتقاد دارد که کاربران بهتر می‌دانند چه چیزی را می‌خواهند، و باید کنترل محیط خودشان را داشته باشند. استفاده از فایل متمرکز شده بر ‎/etc/bashrc‎-شکل، مغایر ماهیت Unix است. ‎~/.bashrc‎ شامل مستعارها، توابع و تنظیمات به شدت شخصی می‌باشد. توجیه قابل‌قبولی برای تحمیل یک انتخاب شخصی از مستعارها (مخصوصاً موارد مشمئز کننده ناگواری مانند ‎alias rm='rm -i'‎) برای جملگی کاربران! وجود ندارد.

• معمولاً شما نیاز ندارید متغیر ‎PROMPT_COMMAND‎ را برای نمایش یک اعلان به کار ببرید. به جای آن لازم است از PS1 استفاده کنید. محتویات PS1 (با رشته‌های backslash معین که در لحظه توسط Bash تفسیر می‌گردند) هر نوبت که لازم باشد Bash اعلان را نشان بدهد، نمایش داده می‌شوند. از طرف دیگر ‎PROMPT_COMMAND‎، مجموعه‌ای از دستورات است( در عوض مواردی برای نمایش) که درست قبل ازآن که PS1 نمایش داده شود، اجرا می‌گردند. PROMPT_COMMAND برای تنظیم متغیرهایی که PS1 استفاده خواهد نمود، یا برای انجام عملیاتی خارج از اعلان، می‌تواند به کار برود.

• اکنون، با در نظر داشتن این موارد، شاید شخص مهیای رسیدگی به آن گردد که، فروشنده سیستم عامل شما چه بیرحمی مرتکب گردیده و آن را خنثی نماید. یک رسیدگی کننده حداقل نیاز دارد که بداند:

  • چه موردی در فایل ‎/etc/bashrc‎ مشکل ساز است.

  • در متغیر PROMPT_COMMAND چه چیزی آزار دهنده است.

  • چه چیزی در متغیر PS1 می‌باشد.

  و مطابق معمول، شخص باید بداند:

  • شما می‌خواهید اعلان شما چطور به نظر آید.

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

---

• پرسش‌های بد (آخرین ویرایش ‎2011-04-02 13:35:41‎ توسط GreyCat)

---

1. مترجم: برای مطالعه بیشتر، سند جامع «چگونه هوشمندانه سؤال کنیم» نوشته اریک ردموند و ترجمه آقایان سعید رسولی و شایان سیف با ویرایش آقای امیر مهری را که قبلاً در ویکی انجمن‌های اوبونتو فارسی (‎http://wiki.ubuntu-ir.org/SmartQuestions‎) منتشر گردیده، ملاحظه نمایید. (بازگشت)

راهنمای آموزشی »

« فهرست پرسش و پاسخ‌ها

---

مشکل در قطع ارتباط با ssh

---

پرسش و پاسخ شماره ۶۳

وقتی من می‌خواهم بعد از اجرای یک job پس‌زمینه‌ای راه دور قطع ارتباط کنم، سرویس‌گیرنده ssh من هنگ می‌کند !

کُد زیر آنچه را انتظار دارید، انجام نخواهد داد:

   ssh me@remotehost 'sleep 120 &'
   # Client hangs for 120 seconds

این ویژگی OpenSSH می‌باشد. سرویس‌گیرنده تا وقتی که ترمینال راه دور هنوز در حال استفاده است، ارتباط را قطع نمی‌کند -- و در حالت ‎sleep 120 &‎، بازهم stdout و stderr به ترمینال متصل هستند.

پاسخ بی‌درنگ به این پرسش شما -- «چگونه می‌توانم ارتباط سرویس گیرنده را قطع کنم به طوری که اعلان پوسته را پس بگیرم؟» -- kill کردن سرویس گیرنده ssh است. البته می‌توانید این کار را با فرمانهای kill یا pkill، یا با ارسال سیگنال INT (معمولاً‎ Ctrl-C ‎) برای یک نشست ssh غیرمحاوره‌ای(مانند بالا)، یا برای پوسته محاوره‌ای راه دور با فشردن کلیدهای ‎ <Enter><~><.>‎ (اینتر، مد، نقطه) در پنجره ترمینال سرویس گیرنده، انجام بدهید.

چاره‌جویی طولانی‌تر این مورد، تأمین نمودن آنست که در طرف راه دور تمام توصیف‌گرهای فایل به فایل ثبت وقایع (یا به ‎/dev/null‎) تغییر مسیر داده شوند:

   ssh me@remotehost 'sleep 120 >/dev/null 2>&1 &'
   # فوراً باز می‌گردد

همچنین این مورد در برخی سیستم‌های یونیکسی قدیمی سرویسهای کمکی (daemon) را دوباره راه‌اندازی می‌کند.

   ssh root@hp-ux-box             # پوسته محاوره‌ای‎
   ...                            # روشن می‌کند که مشکل در سیستم‌فایل شبکه است‎
   /sbin/init.d/nfs.client stop   # با این اسکریپت مدیریت می‌شود و autofs 
   /sbin/init.d/nfs.client start  # قبول است (برخلاف لینوکس )‏ HP-UX کشتن آن در
   exit
   # آنرا بکُشید Enter ~ . سرویس گیرنده هنگ می‌کند با استفاده از 

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

اسکریپت ‎/sbin/init.d/nfs.client‎ میراث یونیکس، سرویس‌های کمکی را در پس‌زمینه اجرا می‌کند اما اجازه می‌دهد stdout و stderr آنها به ترمینال متصل شوند(و آنها به طور کامل self-daemonize نیستند). راه حل آن یا تعمیر اسکریپت ناقص init فروشنده یونیکس، یاکُشتن پردازش سرویس گیرنده ssh پس از وقوع این مورد است. مؤلف این گفتار از رویکرد اخیر استفاده می‌کند.

---

پرسش و پاسخ 63 (آخرین ویرایش ‎2011-08-05 18:02:00‎ توسط GreyCat)

راهنمای آموزشی »

« فهرست پرسش و پاسخ‌ها

---