તમે ઈચ્છો છો કે એક ડાઉનલોડ બીજા પ્રોક્સીનો ઉપયોગ કરે અને પછી બધું સામાન્ય થઈ જાય. તમારી shell ની સ્ટાર્ટઅપ ફાઇલ સંપાદિત કરીને તેને પાછું ફેરવવાનું યાદ રહેશે એવી આશા રાખવાની જરૂર નથી.

POSIX પ્રકારની shell માં બાહ્ય કમાન્ડ માટે, કમાન્ડ પહેલાં અસાઇનમેન્ટ મૂકો:

https_proxy=http://proxy.example:8080 curl https://example.com/

તે ડાઉનલોડ માટે ઉદ્દેશાયેલ HTTP એન્ડપોઇન્ટ વાપરો; HTTP પ્રોક્સી યાદી માન્ય જાહેર માર્ગો માટે ઉમેદવારો આપે છે. અસાઇનમેન્ટ તે કમાન્ડના પર્યાવરણને આપવામાં આવે છે. તેની બાળ પ્રક્રિયાઓ મૂલ્ય વારસામાં લઈ શકે છે, પરંતુ કમાન્ડ પૂરી થયા પછી અસાઇનમેન્ટ પિતૃ shell નું હાલનું મૂલ્ય બદલતું નથી.

ક્લાયન્ટ હજુ પણ નક્કી કરે છે કે શું વાંચવું

shell નું સિન્ટેક્સ પર્યાવરણ બનાવે છે; તે નેટવર્ક માર્ગ ફરજિયાત કરતું નથી. એપ્લિકેશન જે ચલ નામોને સમર્થન આપે છે તે વાપરો. હાલના બાયપાસ ચલ, સ્પષ્ટ કમાન્ડ વિકલ્પો અથવા એપ્લિકેશનનું પોતાનું રૂપરેખાંકન પરિણામને હજુ પણ અસર કરી શકે છે.

Bash પર્યાવરણ દસ્તાવેજીકરણ કમાન્ડ-ઉપસર્ગની વર્તણૂક સમજાવે છે. shell ફંક્શન, ખાસ બિલ્ટઇન અથવા shell સિન્ટેક્સ હોય તેવી કમાન્ડમાં વધારાના વ્યાપના નિયમો હોઈ શકે છે, તેથી ઉપરનું સરળ ઉદાહરણ જાણી જોઈને બાહ્ય પ્રોગ્રામ વાપરે છે.

ઘણી કમાન્ડ માટે, સબશેલ વાપરો

(
  export http_proxy=http://proxy.example:8080
  export https_proxy=http://proxy.example:8080
  command-one
  command-two
)

કૌંસમાંનો સમૂહ પોતાના shell પર્યાવરણ સાથે ચાલે છે. ઉદાહરણના કમાન્ડ નામોને તમે ચલાવવા માંગતા પ્રોગ્રામ્સથી બદલો. આ પેટર્ન જૂનું મૂલ્ય સાચવવું, તેના પર લખવું અને દરેક સંભવિત નિષ્ફળતા પછી હાથે પુનઃસ્થાપિત કરવાના નાજુક ક્રમને ટાળે છે.

shell ઇતિહાસમાં નકલ થતા ઉદાહરણોથી રહસ્યોને દૂર રાખો. એ પણ યાદ રાખો કે sudo પર્યાવરણને ફિલ્ટર કરી શકે છે; બાહ્ય કમાન્ડને દેખાતું ચલ આપોઆપ દરેક વિશેષાધિકાર સીમામાંથી પસાર થતું નથી. કામચલાઉ વ્યાપ અને વાસ્તવિક પ્રોક્સી પસંદગી અલગ પ્રશ્નો રહે છે.

સંબંધિત લેખો