Bir API uç noktasını dışa aktaran VPN kancası, başlattığı süreçlerin ortamını değiştirir, tünel açıldığında zaten açık olan terminalinkini değil. Tam da bu tek ayrım, «araç hâlâ genel uç noktayı çağırıyor» bildirimlerinin çoğunu açıklar. Ayarı koymak için iki kullanışlı yer vardır ve seçim, onu kimin tükettiğine ve ne sıklıkla değiştiğine bağlıdır. Bir başlangıç betiği daha eklemeden önce ikisini karşılaştırın.

Ayarın yaşayabileceği iki yer

İlk seçenek komutun kendisindeki bir önektir: değer yalnızca o tek çağrı için vardır ve onunla birlikte kaybolur. İkinci seçenek bağlantı kancasının içindeki bir dışa aktarmadır ve o noktadan sonra kancanın başlattığı her sürece ulaşır. Erişim ve ömür bakımından farklıdırlar, sözdizimi bakımından değil, ve bu fark arızaların çoğunu belirler.

PropertyPrefix on the commandExport from the hook
Who receives itThat invocation onlyChildren the hook starts
LifetimeUntil the process exitsUntil the hook's own session ends
LeakageScoped to one commandApplies to later commands in that session
Repeat costEvery invocationOnce per connection
Works for an open editorNo, unless the editor is started with itNo

Tablo kancayı ucuz gösterir ve gerçek faturayı gizler: görevle hiç ilgisi olmayan komutlar için de özel bir uç nokta seçer. Her satırı bir tercih değil, kısıt olarak okuyun. Uç nokta göreve göre değişiyorsa, tek tuş vuruşuna mal olsa da önek isabetlilikte kazanır.

Kanca neden zaten açık bir kabuğa ulaşamaz

Ortam değişkenleri bir sürece süreç imgesi oluşturulurken verilir. Bağlantıdan önce başlayan bir kabuk aldığı kopyayı korur ve kancanın içinde çalıştırılan bir dışa aktarma makinedeki her sürece yapılan bir yayın değildir. Onu yalnızca kancanın kendi alt süreçleri miras alır. Bir kabuğun kendi alt süreçleri, başladıkları anda kabuğun elinde ne varsa onu alır, bu yüzden aynı komut bir terminalde çalışıp diğerinde başarısız olabilir.

Aynısı grafik bir düzenleyici için de geçerlidir. Eklenti sunucusu, tümleşik terminali ve arka plandaki dil sunucusu başlatmada çatallandı ve kendi kopyalarını tutuyor. Bir klasörü yeniden açmak bu alt süreçleri mutlaka yeniden başlatmaz, bu yüzden eklediğiniz ayar yine de hiç ulaşmaz.

En ucuz test, değişkeni çalışan kabuktan değil, başarısız olan yerden yazdırmaktır. Başarısız süreç tünelden önce başladıysa, dışa aktarmanın hiç şansı olmamıştır.

Komut başına biçim, yazılmış hâliyle

Bir önek, seçimi onu kullanan komutun içinde görünür tutar; bu, uç nokta görevler arasında değiştiğinde yardımcı olur:

env INTERNAL_API='https://internal-api.example.net:8443' my-work-tool

Komut yalnızca örnektir: my-work-tool bir yer tutucudur ve INTERNAL_API bir VPN standardı değildir, bu yüzden gerçekte çalıştırdığınız programın belgelenmiş ayarını ve kendi onaylı sunucunuzu yazın. Aynı satıra bir belirteç veya parola koymayın, çünkü kabuk geçmişine düşer.

Birden çok komut tek bir göreve aitse, kısa ve gözden geçirilmiş bir sarma betiği değişkenleri ayarlar ve ardından onları başlatır. Böylece tek bir tanım kalır ve değer terminaldeki her gelecek komut için genel hâle gelmez.

Yeniden yükleyin, yeniden başlatın ya da bırakın

Zaten çalışan bir araç için, varsa kendi yeniden yüklemesini veya çalışma alanı profilini tercih edin. Yoksa çalışmanızı kaydedin ve ayarı okuyan bileşeni yeniden başlatın; bu genellikle düzenleyici penceresi değil bir dil sunucusudur. Pencereyi yeniden başlatıp alt süreçlerin onu izlediğini varsaymak, yeniden yüklemenin çalışmıyor gibi görünmesinin tam nedeni budur.

Bağlantının kesilmesi ayrı bir karardır. Duraklatma, kapatma veya yeniden bağlanma uygulamaya aittir ve uç nokta değişkeni bunu denetlemez. Değişkeni bir adres seçen yapılandırma olarak ele alın, sonrasında hangi ağ trafiğinin kullanılabileceğine dair bir kural olarak değil, ve iki konu ayrılabilir kalır.

İlgili makaleler