VPN ٹول کی ترتیبات: لانچ کے وقت کا ماحول یا ہک میں ایکسپورٹ؟
ہک اپنے چائلڈ پروسیس شروع کرتا ہے، وہ شیل نہیں جو آپ پہلے ہی کھول چکے ہیں۔ لانچ کے وقت کا ماحول نجی اینڈ پوائنٹ کو صرف اسی ایک کمانڈ پر رکھتا ہے جسے اس کی ضرورت ہے۔
API اینڈ پوائنٹ ایکسپورٹ کرنے والا VPN ہک اپنے شروع کردہ پروسیسوں کا ماحول بدلتا ہے، اس ٹرمینل کا نہیں جو ٹنل اٹھنے کے وقت پہلے ہی کھلا تھا۔ یہی ایک فرق زیادہ تر رپورٹوں کی وضاحت کرتا ہے کہ «ٹول اب بھی عوامی اینڈ پوائنٹ کو کال کر رہا ہے»۔ ترتیب رکھنے کی دو کارآمد جگہیں ہیں، اور انتخاب اس پر منحصر ہے کہ اسے کون استعمال کرتا ہے اور یہ کتنی بار بدلتی ہے۔ مزید اسٹارٹ اپ اسکرپٹ شامل کرنے سے پہلے دونوں کا موازنہ کریں۔
دو جگہیں جہاں ترتیب رہ سکتی ہے
پہلا اختیار خود کمانڈ پر ایک سابقہ ہے: قدر صرف اسی ایک کال کے لیے ہوتی ہے اور اسی کے ساتھ غائب ہو جاتی ہے۔ دوسرا اختیار کنکشن ہک کے اندر ایکسپورٹ ہے، جو اس مقام کے بعد ہک کے شروع کردہ ہر پروسیس تک پہنچتا ہے۔ یہ رسائی اور عمر میں مختلف ہیں، نحو میں نہیں، اور یہی فرق زیادہ تر ناکامیوں کا فیصلہ کرتا ہے۔
| Property | Prefix on the command | Export from the hook |
|---|---|---|
| Who receives it | That invocation only | Children the hook starts |
| Lifetime | Until the process exits | Until the hook's own session ends |
| Leakage | Scoped to one command | Applies to later commands in that session |
| Repeat cost | Every invocation | Once per connection |
| Works for an open editor | No, unless the editor is started with it | No |
جدول ہک کو سستا دکھاتا ہے اور اصل بل چھپاتا ہے: یہ ان کمانڈوں کے لیے بھی نجی اینڈ پوائنٹ چنتا ہے جن کا کام سے کوئی تعلق نہیں۔ ہر قطار کو ترجیح نہیں، پابندی کے طور پر پڑھیں۔ اگر اینڈ پوائنٹ ہر کام کے ساتھ بدلتا ہے تو ایک کی اسٹروک کی قیمت دے کر بھی سابقہ درستگی میں جیتتا ہے۔
ہک پہلے سے کھلے شیل تک کیوں نہیں پہنچ سکتا
ماحول کے متغیرات پروسیس کو اس وقت دیے جاتے ہیں جب پروسیس کی شبیہ بنتی ہے۔ کنکشن سے پہلے شروع ہوا شیل اپنی موصول شدہ نقل رکھتا ہے، اور ہک کے اندر چلایا گیا ایکسپورٹ مشین کے ہر پروسیس تک نشریات نہیں ہے۔ اسے صرف ہک کے اپنے بچے ورثے میں پاتے ہیں۔ شیل کے اپنے بچے وہ لیتے ہیں جو شیل کے پاس ان کے شروع ہونے کے لمحے ہوتا ہے، اسی لیے ایک ہی کمانڈ ایک ٹرمینل میں چل سکتی ہے اور دوسرے میں ناکام ہو سکتی ہے۔
یہی بات گرافیکل ایڈیٹر پر بھی لاگو ہوتی ہے۔ اس کا ایکسٹینشن ہوسٹ، اندرونی ٹرمینل اور پس منظر کا لینگویج سرور لانچ کے وقت الگ ہوئے اور اپنی نقلیں رکھتے ہیں۔ فولڈر دوبارہ کھولنے سے وہ بچے لازماً دوبارہ شروع نہیں ہوتے، اس لیے آپ کی شامل کردہ ترتیب پھر بھی کبھی نہیں پہنچتی۔
سب سے سستا امتحان یہ ہے کہ متغیر کو اس جگہ سے چھاپیں جہاں ناکامی ہوتی ہے، اس شیل سے نہیں جو کام کرتا ہے۔ اگر ناکام ہونے والا پروسیس ٹنل سے پہلے شروع ہوا تھا تو ایکسپورٹ کو کوئی موقع نہیں ملا۔
فی کمانڈ شکل، لکھی ہوئی
سابقہ انتخاب کو اسی کمانڈ میں نظر آتا رکھتا ہے جو اسے استعمال کرتی ہے، جو کاموں کے درمیان اینڈ پوائنٹ بدلنے پر مدد کرتا ہے:
env INTERNAL_API='https://internal-api.example.net:8443' my-work-toolکمانڈ صرف مثال ہے: my-work-tool ایک پلیس ہولڈر ہے اور INTERNAL_API VPN معیار نہیں ہے، اس لیے وہ ترتیب رکھیں جو آپ کے حقیقی طور پر چلائے جانے والے پروگرام کی دستاویزی شکل ہے اور اپنا منظور شدہ ہوسٹ۔ ایک ہی سطر میں ٹوکن یا پاس ورڈ نہ رکھیں، کیونکہ وہ شیل کی تاریخ میں جاتا ہے۔
جب کئی کمانڈیں ایک ہی کام کی ہوں، تو ایک مختصر جائزہ شدہ ریپر اسکرپٹ متغیرات مقرر کرتا ہے اور پھر انہیں شروع کرتا ہے۔ اس طرح ایک ہی تعریف رہتی ہے، قدر ٹرمینل کی ہر آئندہ کمانڈ کے لیے عالمی نہیں بنتی۔
دوبارہ لوڈ کریں، دوبارہ شروع کریں یا چھوڑ دیں
پہلے سے چل رہے ٹول کے لیے، اگر ہو تو اس کا اپنا دوبارہ لوڈ یا ورک اسپیس پروفائل ترجیح دیں۔ ورنہ کام محفوظ کریں اور ترتیب پڑھنے والا جزو دوبارہ شروع کریں، جو اکثر لینگویج سرور ہوتا ہے، ایڈیٹر کی ونڈو نہیں۔ ونڈو دوبارہ شروع کر کے یہ ماننا کہ چائلڈ پروسیس اس کے پیچھے آ گئے، یہی وجہ ہے کہ دوبارہ لوڈ کام نہ کرتا دکھتا ہے۔
منقطع ہونا ایک الگ فیصلہ ہے۔ روکنا، بند کرنا یا دوبارہ جڑنا ایپلیکیشن کا کام ہے، اور اینڈ پوائنٹ متغیر اسے کنٹرول نہیں کرتا۔ متغیر کو پتہ چننے والی ترتیب سمجھیں، بعد میں کون سا نیٹ ورک ٹریفک استعمال ہو سکتا ہے اس بارے میں قاعدہ نہیں، اور دونوں معاملات الگ رہتے ہیں۔