რატომ მუშაობს პროქსის პარამეტრები ტერმინალში, მაგრამ არა სამუშაო მაგიდის გამშვებში

თქვენ ექსპორტავთ პროქსის ტერმინალში. იქ გაშვებული ბრძანება მას იყენებს. სამუშაო მაგიდის ხატულაზე დაწკაპუნება მაინც სხვა მარშრუტს იძლევა. ხატულა ამ ტერმინალის შვილი არ გახდა.

სამუშაო მაგიდის სესია აპლიკაციებს საკუთარი გაშვების მექანიზმით იწყებს. ეს პროცესები იმ გარემოს მემკვიდრეობით იღებენ და არა ყოველ შემდგომ ცვლილებას, რომელიც დაუკავშირებელ ჭურვში გაკეთდა. ამას შეუძლია განსხვავება ახსნას, მაგრამ არ ამტკიცებს, რომ აპლიკაციის პაკეტი დეფექტურია.

Exec ბრძანების აღწერაა და არა ჭურვის სკრიპტი

Desktop Entry სპეციფიკაცია განსაზღვრავს შესრულებად ფაილსა და არგუმენტებს Exec-ისთვის. ის არ გვპირდება ჭურვის ცვლადების გაშლას ან ჭურვის ჩაშენებულ ბრძანებებს.

გარე პროგრამისთვის, რომელიც კითხულობს შესაბამის გარემოს ცვლადს, განზრახ შეზღუდულ გაშვებას შეიძლება ჰქონდეს ასეთი ფორმა:

Exec=env https_proxy=http://proxy.example:8080 /path/to/application

შეცვალეთ როგორც ბოლო წერტილი, ისე შესრულებადი ფაილი. ეს აჩვენებს გაშვების შეტანას და არა გარანტიას, რომ თვითნებური აპლიკაცია წაიკითხავს ამ ცვლადს. ბრაუზერს, რომელსაც საკუთარი გამოკვეთილი პროქსის პოლიტიკა აქვს, მაინც შეუძლია აირჩიოს კონფიგურაციის სხვა წყარო. Chrome-ისთვის შეინახეთ მისი პროქსის არგუმენტი მომხმარებლის გამშვებში.

ნუ დაწერთ Exec=export ... და ნუ დაელოდებით, რომ სამუშაო მაგიდა მას თქვენს შესვლის ჭურვად განმარტავს. გაითვალისწინეთ აგრეთვე სამუშაო მაგიდის ჩანაწერის ბრჭყალების წესები და მხარდაჭერილი ველის კოდები; ისინი სხვა პარსერია.

შეამოწმეთ, გაშვდა თუ არა რაიმე ახალი

ზოგიერთი აპლიკაცია მოთხოვნას უკვე მოქმედ ინსტანციას უგზავნის. ზოგიერთი ჩანაწერი იყენებს D-Bus გააქტიურებას, რომელსაც საკუთარი გაშვების გზა აქვს. ხატულაზე ახალი დაწკაპუნება არ ქმნის ახალ პროცესს ახლახან შეცვლილი Exec გარემოთი.

განსაზღვრეთ მოთხოვნის გამომწვევი ინსტანცია და კონფიგურაცია, რომელსაც ის ნამდვილად ფლობს. კონტროლირებულ ახალ გაშვებას შეუძლია შეამციროს შედარება, როცა ეს მიზანშეწონილია. მოერიდეთ აპლიკაციის ხელახალ დაყენებას, სანამ დაადგენთ, მიღწევია თუ არა მას განზრახული გარემო საერთოდ.