Erlang 21 - 7. Applications

7 आवेदन




erlang

7 आवेदन

यह खंड कर्नेल में app(4) और application(3) मैनुअल पेजों के साथ पढ़ा जाना है।

7.1 अनुप्रयोग अवधारणा

जब आपने कुछ विशिष्ट कार्यक्षमता को लागू करने वाले कोड को लिखा है, तो आप कोड को एक अनुप्रयोग में बनाना चाह सकते हैं, अर्थात, एक घटक जिसे एक इकाई के रूप में शुरू और बंद किया जा सकता है, और जिसे अन्य प्रणालियों में भी पुन: उपयोग किया जा सकता है।

ऐसा करने के लिए, application callback module बनाएं, और वर्णन करें कि आवेदन कैसे शुरू और बंद किया जाना है।

फिर, एक एप्लिकेशन स्पेसिफिकेशन की आवश्यकता होती है, जिसे application resource file में डाला जाता है। अन्य बातों के अलावा, यह फ़ाइल निर्दिष्ट करती है कि किस मॉड्यूल में एप्लिकेशन शामिल है और कॉलबैक मॉड्यूल का नाम।

यदि आप systools उपयोग systools , पैकेजिंग कोड के लिए systools / ओटीपी उपकरण (देखें Releases ), प्रत्येक एप्लिकेशन के लिए कोड को एक पूर्व-निर्धारित directory structure बाद एक अलग निर्देशिका में रखा गया है।

7.2 आवेदन कॉलबैक मॉड्यूल

आवेदन के लिए कोड को कैसे शुरू और बंद करना है, अर्थात् पर्यवेक्षण ट्री, दो कॉलबैक फ़ंक्शन द्वारा वर्णित है:

start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State}
stop(State)
  • start को तब शुरू किया जाता है जब आवेदन शुरू करना और शीर्ष पर्यवेक्षक को शुरू करके पर्यवेक्षण ट्री बनाना है। यह शीर्ष पर्यवेक्षक और एक वैकल्पिक पद, State , जो कि चूक है [] के पीआईडी ​​को वापस करने की उम्मीद है। इस शब्द को इस तरह से stop दिया जाता है।
  • StartType आमतौर पर परमाणु normal । यह केवल एक अधिग्रहण या विफलता के मामले में अन्य मान हैं, Distributed Applications देखें।
  • StartArgs को application resource file में कुंजी mod द्वारा परिभाषित किया गया है।
  • stop/1 को एप्लिकेशन को stop/1 बाद कहा जाता है और किसी भी आवश्यक सफाई को करना है। अनुप्रयोग के वास्तविक ठहराव, अर्थात्, पर्यवेक्षण के पेड़ का बंद होना, Starting and Stopping Applications में वर्णित के अनुसार स्वचालित रूप से नियंत्रित किया जाता है।

Supervisor Behaviour से Supervisor Behaviour पेड़ की पैकेजिंग के लिए एक एप्लिकेशन कॉलबैक मॉड्यूल का उदाहरण:

-module(ch_app).
-behaviour(application).

-export([start/2, stop/1]).

start(_Type, _Args) ->
    ch_sup:start_link().

stop(_State) ->
    ok.

एक लाइब्रेरी एप्लिकेशन जिसे शुरू या बंद नहीं किया जा सकता है, उसे किसी एप्लिकेशन कॉलबैक मॉड्यूल की आवश्यकता नहीं है।

7.3 अनुप्रयोग संसाधन फ़ाइल

किसी एप्लिकेशन को परिभाषित करने के लिए, एक एप्लिकेशन स्पेसिफिकेशन बनाया जाता है, जिसे एप्लिकेशन रिसोर्स फ़ाइल में या संक्षेप में .app फ़ाइल में रखा जाता है:

{application, Application, [Opt1,...,OptN]}.
  • Application , एक परमाणु, अनुप्रयोग का नाम है। फ़ाइल का नाम Application.app होना चाहिए।
  • प्रत्येक Opt एक टपल {Key,Value} , जो एप्लिकेशन की एक निश्चित संपत्ति को परिभाषित करता है। सभी कुंजियाँ वैकल्पिक हैं। डिफ़ॉल्ट मान का उपयोग किसी भी छोड़ी गई कुंजी के लिए किया जाता है।

एक पुस्तकालय अनुप्रयोग libapp लिए एक न्यूनतम .app फ़ाइल की सामग्री इस प्रकार है:

{application, libapp, []}.

एक न्यूनतम .app फ़ाइल की सामग्री ch_app.app पर्यवेक्षण वृक्ष के अनुप्रयोग की तरह ch_app की तरह दिखता है:

{application, ch_app,
 [{mod, {ch_app,[]}}]}.

कुंजी mod कॉलबैक मॉड्यूल को परिभाषित करता है और आवेदन का तर्क शुरू करता है, इस मामले में क्रमशः ch_app और [] । इसका मतलब है कि जब आवेदन शुरू किया जाना है, तो निम्नलिखित को कहा जाता है:

ch_app:start(normal, [])

जब आवेदन बंद कर दिया जाता है तो निम्नलिखित को कहा जाता है।

ch_app:stop([])

systools का उपयोग करते systools , पैकेजिंग कोड के लिए systools / ओटीपी टूल (अनुभाग Releases देखें), कुंजी description , vsn , modules , registered , और applications भी निर्दिष्ट किए जाने हैं:

{application, ch_app,
 [{description, "Channel allocator"},
  {vsn, "1"},
  {modules, [ch_app, ch_sup, ch3]},
  {registered, [ch3]},
  {applications, [kernel, stdlib, sasl]},
  {mod, {ch_app,[]}}
 ]}.
  • description - एक संक्षिप्त विवरण, एक स्ट्रिंग। चूक "" के लिए।
  • vsn - संस्करण संख्या, एक स्ट्रिंग। चूक "" के लिए।
  • modules - इस एप्लिकेशन द्वारा शुरू किए गए सभी मॉड्यूल। systools बूट स्क्रिप्ट और टार फ़ाइलों को systools समय इस सूची का उपयोग करता है। एक मॉड्यूल को केवल एक अनुप्रयोग में परिभाषित किया जाना चाहिए। चूक []
  • registered - आवेदन में पंजीकृत प्रक्रियाओं के सभी नाम। systools इस सूची का उपयोग अनुप्रयोगों के बीच नाम के टकराव का पता लगाने के लिए करता है। चूक []
  • applications - इस आवेदन के शुरू होने से पहले सभी आवेदन शुरू होने चाहिए। systools इस सूची का उपयोग सही बूट स्क्रिप्ट उत्पन्न करने के लिए करता है। चूक [] । ध्यान दें कि सभी अनुप्रयोगों में कम से कम कर्नेल और STDLIB पर निर्भरता है।
ध्यान दें

एप्लिकेशन संसाधन फ़ाइल के सिंटैक्स और सामग्री के बारे में जानकारी के लिए, कर्नेल में app मैनुअल पेज देखें।

7.4 निर्देशिका संरचना

जब systools का उपयोग करके पैकेजिंग कोड, प्रत्येक एप्लिकेशन के लिए कोड को एक अलग निर्देशिका, lib/Application-Vsn में रखा जाता है, जहां Vsn संस्करण संख्या होती है।

यह जानना उपयोगी हो सकता है, भले ही systools का उपयोग न किया गया हो, क्योंकि Erlang / OTP को OTP सिद्धांतों के अनुसार पैक किया जाता है और इस प्रकार यह एक विशिष्ट निर्देशिका संरचना के साथ आता है। कोड सर्वर (कोड को देखें code(3) मैनुअल पेज कर्नेल में) स्वचालित रूप से उच्चतम संस्करण संख्या के साथ निर्देशिका से कोड का उपयोग करता है, यदि किसी एप्लिकेशन का एक से अधिक संस्करण मौजूद है।

एक विकास पर्यावरण के लिए निर्देशिका संरचना दिशानिर्देश

विकास के लिए कोई भी निर्देशिका संरचना तब तक पर्याप्त होगी जब तक कि जारी निर्देशिका संरचना description below का पालन नहीं करती है, लेकिन यह प्रोत्साहित किया जाता है कि विकास निर्देशिका में उसी निर्देशिका संरचना का भी उपयोग किया जाए। संस्करण संख्या को एप्लिकेशन डायरेक्टरी नाम से छोड़ दिया जाना चाहिए क्योंकि यह रिलीज़ चरण की एक कलाकृति है।

कुछ उप-निर्देशिकाओं की आवश्यकता होती है । कुछ उप-निर्देशिकाएं वैकल्पिक हैं , जिसका अर्थ है कि इसका उपयोग केवल तभी किया जाना चाहिए जब एप्लिकेशन को स्वयं इसकी आवश्यकता हो। अंत में, कुछ उप-निर्देशिकाओं की सिफारिश की जाती है , जिसका अर्थ है कि यह प्रोत्साहित किया जाता है और इसका उपयोग यहां वर्णित के रूप में किया जाता है। उदाहरण के लिए, दस्तावेज और परीक्षण दोनों को एक उचित ओटीपी आवेदन के रूप में समझा जाने के लिए एक आवेदन में मौजूद होने के लिए प्रोत्साहित किया जाता है।

─ ${application}
  ├── doc
  │   ├── internal
  │   ├── examples
  │   └── src
  ├── include
  ├── priv
  ├── src
  │   └── ${application}.app.src
  └── test
  • src - आवश्यक है। Erlang स्रोत कोड, .app फ़ाइल के स्रोत और आंतरिक में एप्लिकेशन द्वारा उपयोग की गई फ़ाइलें शामिल हैं। स्रोत फ़ाइलों को व्यवस्थित करने के लिए src भीतर अतिरिक्त उप-निर्देशिकाओं को नामस्थान के रूप में उपयोग किया जा सकता है। ये निर्देशिका कभी एक स्तर से अधिक गहरी नहीं होनी चाहिए।
  • priv - वैकल्पिक। एप्लिकेशन विशिष्ट फ़ाइलों के लिए उपयोग किया जाता है।
  • include - वैकल्पिक। जनता के लिए उपयोग की जाने वाली फाइलें शामिल हैं जिन्हें अन्य अनुप्रयोगों से उपलब्ध होना चाहिए।
  • doc - अनुशंसित। किसी भी स्रोत प्रलेखन को यहां उप-निर्देशिकाओं में रखा जाना चाहिए।
  • doc/internal - अनुशंसित कोई भी दस्तावेज जो इस आवेदन के बारे में कार्यान्वयन विवरण का वर्णन करता है, प्रकाशन के लिए अभिप्रेत नहीं है, उसे यहां रखा जाना चाहिए।
  • doc/examples - अनुशंसित इस एप्लिकेशन का उपयोग कैसे करें के उदाहरणों के लिए स्रोत कोड यहां रखा जाना चाहिए। यह प्रोत्साहित किया जाता है कि इस निर्देशिका से सार्वजनिक प्रलेखन के लिए उदाहरण प्रस्तुत किए जाते हैं।
  • doc/src - अनुशंसित। प्रलेखन के लिए सभी स्रोत फाइलें, जैसे कि मार्कडाउन, एससीआईडॉक या एक्सएमएल-फाइलें, यहां रखी जानी चाहिए।
  • test - अनुशंसित। परीक्षण से संबंधित सभी फाइलें, जैसे कि परीक्षण सूट और परीक्षण विनिर्देश, को यहां रखा जाना चाहिए।

विकास के वातावरण में अन्य निर्देशिकाओं की आवश्यकता हो सकती है। यदि Erlang के अलावा अन्य भाषाओं के स्रोत कोड का उपयोग किया जाता है, उदाहरण के लिए NIF के लिए C- कोड, तो उस कोड को एक अलग निर्देशिका में रखा जाना चाहिए। इस तरह की निर्देशिकाओं को भाषा के नाम के साथ उपसर्ग करने की सिफारिश की जाती है, उदाहरण के लिए c_src for C, java_src जावा के लिए या go_src गो के लिए। _src प्रत्यय के साथ निर्देशिकाएँ यह इंगित करता है कि यह अनुप्रयोग और संकलन चरण का एक हिस्सा है। अंतिम बिल्ड कलाकृतियों को priv/lib या priv/bin निर्देशिकाओं को लक्षित करना चाहिए।

निजी निर्देशिका संपत्ति रखती है कि आवेदन रनटाइम के दौरान की जरूरत है। कार्यकारी priv/bin में रहना चाहिए और गतिशील रूप से जुड़े पुस्तकालयों को priv/lib में निवास करना चाहिए। अन्य परिसंपत्तियां priv निर्देशिका के भीतर रहने के लिए स्वतंत्र हैं, लेकिन यह अनुशंसा की जाती है कि यह एक संरचित तरीके से ऐसा करता है।

अन्य भाषाओं की स्रोत फाइलें, जो ASN.1 या Mibs जैसे Erlang कोड जनरेट करती हैं, को निर्देशिका में, शीर्ष स्तर पर या src , स्रोत भाषा के समान नाम के साथ, उदाहरण के लिए asn1 और mibs । बिल्ड कलाकृतियों को उनकी संबंधित भाषा निर्देशिका में रखा जाना चाहिए, जैसे कि Erlang कोड के लिए src या जावा कोड के लिए java_src

रिलीज के लिए .app फ़ाइल एक विकास के माहौल में ebin निवास कर सकती है लेकिन यह प्रोत्साहित किया जाता है कि यह बिल्ड चरण की एक कलाकृतियों है। कन्वेंशन द्वारा एक .app.src फ़ाइल का उपयोग किया जाता है, जो src डायरेक्टरी में रहता है। यह फ़ाइल .app फ़ाइल के रूप में लगभग समान है, लेकिन कुछ चरणों को बिल्ड चरण के दौरान बदला जा सकता है, जैसे कि एप्लिकेशन संस्करण।

निर्देशिका नामों को कैपिटल नहीं किया जाना चाहिए।

यह खाली निर्देशिकाओं को छोड़ने के लिए प्रोत्साहित किया जाता है।

एक जारी प्रणाली के लिए निर्देशिका संरचना

एक जारी किए गए एप्लिकेशन को एक निश्चित संरचना का पालन करना चाहिए।

─ ${application}-${version}
  ├── bin
  ├── doc
  │   ├── html
  │   ├── man[1-9]
  │   ├── pdf
  │   ├── internal
  │   └── examples
  ├── ebin
  │   └── ${application}.app
  ├── include
  ├── priv
  │   ├── lib
  │   └── bin
  └── src
  • src - वैकल्पिक। Erlang स्रोत कोड और आंतरिक में एप्लिकेशन द्वारा उपयोग की गई फ़ाइलें शामिल हैं। यह निर्देशिका अब रिलीज़ किए गए एप्लिकेशन में आवश्यक नहीं है।
  • ebin - आवश्यक। Erlang ऑब्जेक्ट कोड, beam फ़ाइलों को शामिल करता है। .app फ़ाइल को भी यहाँ रखा जाना चाहिए।
  • priv - वैकल्पिक। एप्लिकेशन विशिष्ट फ़ाइलों के लिए उपयोग किया जाता है। code:priv_dir/1 का उपयोग इस निर्देशिका को एक्सेस करने के लिए किया जाना है।
  • priv/lib - अनुशंसित। कोई भी साझा-ऑब्जेक्ट फ़ाइलें जो अनुप्रयोग द्वारा उपयोग की जाती हैं, जैसे कि NIF या लिंक्ड-इन-ड्राइवर, को यहां रखा जाना चाहिए।
  • priv/bin - अनुशंसित। किसी भी निष्पादन योग्य जो कि पोर्ट-प्रोग्राम जैसे एप्लिकेशन द्वारा उपयोग किया जाता है, उसे यहां रखा जाना चाहिए।
  • include - वैकल्पिक। जनता के लिए उपयोग की जाने वाली फाइलें शामिल हैं जिन्हें अन्य अनुप्रयोगों से उपलब्ध होना चाहिए।
  • bin - वैकल्पिक। कोई भी निष्पादन योग्य जो कि एस्क्रीप्ट या शेल-स्क्रिप्ट जैसे एप्लिकेशन का एक उत्पाद है, को यहां रखा जाना चाहिए।
  • doc - वैकल्पिक। किसी भी जारी किए गए प्रलेखन को यहां उप-निर्देशिका में रखा जाना चाहिए।
  • doc/man1 - अनुशंसित। एप्लिकेशन निष्पादन के लिए मैन पेज।
  • doc/man3 - अनुशंसित मॉड्यूल एपीआई के लिए मैन पेज।
  • doc/man6 - अनुशंसित। अनुप्रयोग अवलोकन के लिए मैन पेज।
  • doc/html - वैकल्पिक। संपूर्ण अनुप्रयोग के लिए HTML पृष्ठ।
  • doc/pdf - वैकल्पिक। पूरे आवेदन के लिए पीडीएफ प्रलेखन।

डीबगिंग उद्देश्यों के लिए रिलीज़ करने के लिए src निर्देशिका उपयोगी हो सकती है, लेकिन आवश्यक नहीं है। include निर्देशिका को केवल तभी जारी किया जाना चाहिए जब अनुप्रयोगों में सार्वजनिक फ़ाइलें शामिल हों।

इस तरह से जारी करने की सिफारिश की जाने वाली एकमात्र दस्तावेज मैन पेज हैं। HTML और PDF सामान्य रूप से किसी अन्य तरीके से वितरित की जाएगी।

यह खाली निर्देशिकाओं को छोड़ने के लिए प्रोत्साहित किया जाता है।

7.5 आवेदन नियंत्रक

जब एक एरलैंग रनटाइम सिस्टम शुरू किया जाता है, तो कर्नेल एप्लिकेशन के हिस्से के रूप में कई प्रक्रियाएं शुरू की जाती हैं। इन प्रक्रियाओं में से एक अनुप्रयोग नियंत्रक प्रक्रिया है, जिसे application_controller रूप में पंजीकृत किया गया application_controller

अनुप्रयोगों पर सभी संचालन अनुप्रयोग नियंत्रक द्वारा समन्वित होते हैं। यह मॉड्यूल application में फ़ंक्शन के माध्यम से इंटरैक्ट किया जाता है, कर्नेल में application(3) मैनुअल पेज देखें। विशेष रूप से, अनुप्रयोगों को लोड किया जा सकता है, अनलोड किया जा सकता है, शुरू किया जा सकता है, और रोका जा सकता है।

7.6 लोडिंग और अनलोडिंग एप्लिकेशन

आवेदन शुरू करने से पहले, इसे लोड किया जाना चाहिए। अनुप्रयोग नियंत्रक .app फ़ाइल से जानकारी पढ़ता है और संग्रहीत करता है:

1> application:load(ch_app).
ok
2> application:loaded_applications().
[{kernel,"ERTS  CXC 138 10","2.8.1.3"},
 {stdlib,"ERTS  CXC 138 10","1.11.4.3"},
 {ch_app,"Channel allocator","1"}]

एक एप्लिकेशन जिसे रोका गया है, या कभी भी शुरू नहीं किया गया है, उसे अनलोड किया जा सकता है। एप्लिकेशन के बारे में जानकारी एप्लिकेशन कंट्रोलर के आंतरिक डेटाबेस से मिटा दी जाती है।

3> application:unload(ch_app).
ok
4> application:loaded_applications().
[{kernel,"ERTS  CXC 138 10","2.8.1.3"},
 {stdlib,"ERTS  CXC 138 10","1.11.4.3"}]
ध्यान दें

लोड हो रहा है / किसी एप्लिकेशन को उतारना एप्लिकेशन द्वारा उपयोग किए गए कोड को लोड / अनलोड नहीं करता है। कोड लोडिंग सामान्य तरीके से की जाती है।

7.7 शुरू करना और अनुप्रयोग रोकना

कॉल करके एक एप्लिकेशन शुरू किया जाता है:

5> application:start(ch_app).
ok
6> application:which_applications().
[{kernel,"ERTS  CXC 138 10","2.8.1.3"},
 {stdlib,"ERTS  CXC 138 10","1.11.4.3"},
 {ch_app,"Channel allocator","1"}]

यदि एप्लिकेशन पहले से लोड नहीं है, तो एप्लिकेशन कंट्रोलर पहले application:load/1 का उपयोग करके इसे लोड करता है। यह applications कुंजी के मूल्य की जांच करता है, यह सुनिश्चित करने के लिए कि इस एप्लिकेशन के चलने से पहले शुरू होने वाले सभी एप्लिकेशन।

एप्लिकेशन कंट्रोलर तब एप्लिकेशन के लिए एप्लिकेशन मास्टर बनाता है। एप्लिकेशन मास्टर एप्लिकेशन में सभी प्रक्रियाओं का समूह नेता बन जाता है। I / O को पिछले समूह के नेता के पास भेज दिया जाता है, हालांकि, यह उन प्रक्रियाओं की पहचान करने का एक तरीका है जो अनुप्रयोग से संबंधित हैं। उदाहरण के लिए किसी भी प्रक्रिया से खुद को खोजने के लिए, या, पारस्परिक रूप से उन सभी को मारने के लिए जब यह समाप्त हो जाता है।

एप्लिकेशन मास्टर मॉड्यूल में एप्लिकेशन कॉलबैक फ़ंक्शन start/2 को कॉल करके एप्लिकेशन start/2 करता है, और प्रारंभ तर्क के साथ, .app फ़ाइल में mod कुंजी द्वारा परिभाषित किया गया है।

एक एप्लिकेशन को रोका गया है, लेकिन अनलोड नहीं किया गया है, कॉल करके:

7> application:stop(ch_app).
ok

आवेदन मास्टर शीर्ष पर्यवेक्षक को बंद करने के लिए कहकर आवेदन को रोक देता है। शीर्ष पर्यवेक्षक अपनी सभी बाल प्रक्रियाओं को बंद करने के लिए कहता है, और इसी तरह; पूरे पेड़ को उल्टे स्टार्ट ऑर्डर में समाप्त किया जाता है। एप्लिकेशन मास्टर तब mod कॉल द्वारा परिभाषित मॉड्यूल में एप्लिकेशन कॉलबैक फ़ंक्शन stop/1 को कॉल करता है।

7.8 किसी एप्लिकेशन को कॉन्फ़िगर करना

कॉन्फ़िगरेशन मापदंडों का उपयोग करके एक एप्लिकेशन को कॉन्फ़िगर किया जा सकता है। ये {Par,Val} .app फ़ाइल में एक कुंजी env द्वारा निर्दिष्ट {Par,Val} tuples की एक सूची है।

{application, ch_app,
 [{description, "Channel allocator"},
  {vsn, "1"},
  {modules, [ch_app, ch_sup, ch3]},
  {registered, [ch3]},
  {applications, [kernel, stdlib, sasl]},
  {mod, {ch_app,[]}},
  {env, [{file, "/usr/local/log"}]}
 ]}.

Par एक परमाणु होना है। Val कोई भी शब्द हो। एप्लिकेशन को कॉल करके एक कॉन्फ़िगरेशन पैरामीटर का मान पुनः प्राप्त कर सकते हैं application:get_env(App, Par) या इसी तरह के कई फ़ंक्शन, कर्नेल में application(3) मैनुअल पेज देखें।

उदाहरण:

% erl
Erlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]

Eshell V5.2.3.6  (abort with ^G)
1> application:start(ch_app).
ok
2> application:get_env(ch_app, file).
{ok,"/usr/local/log"}

.app फ़ाइल के मानों को सिस्टम कॉन्फ़िगरेशन फ़ाइल में मानों द्वारा ओवरराइड किया जा सकता है। यह एक फाइल है जिसमें प्रासंगिक अनुप्रयोगों के लिए कॉन्फ़िगरेशन पैरामीटर हैं:

[{Application1, [{Par11,Val11},...]},
 ...,
 {ApplicationN, [{ParN1,ValN1},...]}].

सिस्टम कॉन्फ़िगरेशन को Name.config कहा Name.config और Erlang को कमांड-लाइन तर्क -config Name शुरू किया जाना है। विवरण के लिए, कर्नेल में config(4) मैनुअल पेज देखें।

उदाहरण:

एक फ़ाइल test.config निम्नलिखित सामग्री के साथ बनाया गया है:

[{ch_app, [{file, "testlog"}]}].

file का मान .app फ़ाइल में परिभाषित file के मान को ओवरराइड करता है:

% erl -config test
Erlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]

Eshell V5.2.3.6  (abort with ^G)
1> application:start(ch_app).
ok
2> application:get_env(ch_app, file).
{ok,"testlog"}

यदि release handling का उपयोग किया जाता है, तो वास्तव में एक सिस्टम कॉन्फ़िगरेशन फ़ाइल का उपयोग किया जाना है और उस फ़ाइल को sys.config कहा sys.config

.app फ़ाइल के मान और सिस्टम कॉन्फ़िगरेशन फ़ाइल के मान सीधे कमांड लाइन से ओवरराइड किए जा सकते हैं:

% erl -ApplName Par1 Val1 ... ParN ValN

उदाहरण:

% erl -ch_app file '"testlog"'
Erlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]

Eshell V5.2.3.6  (abort with ^G)
1> application:start(ch_app).
ok
2> application:get_env(ch_app, file).
{ok,"testlog"}

7.9 आवेदन शुरू प्रकार

अनुप्रयोग शुरू करते समय एक प्रारंभ प्रकार परिभाषित किया गया है:

application:start(Application, Type)

application:start(Application) कॉलिंग application:start(Application, temporary) के समान है application:start(Application, temporary) । प्रकार भी permanent या transient हो सकता है:

  • यदि कोई स्थायी एप्लिकेशन समाप्त हो जाता है, तो अन्य सभी एप्लिकेशन और रनटाइम सिस्टम भी समाप्त हो जाते हैं।
  • यदि कोई क्षणिक अनुप्रयोग normal कारण के साथ समाप्त normal , तो यह सूचित किया जाता है लेकिन कोई अन्य अनुप्रयोग समाप्त नहीं होता है। यदि एक क्षणिक अनुप्रयोग असामान्य रूप से समाप्त हो जाता है, जो normal अलावा किसी अन्य कारण से normal , तो अन्य सभी अनुप्रयोग और रनटाइम सिस्टम भी समाप्त हो जाते हैं।
  • यदि कोई अस्थायी अनुप्रयोग समाप्त हो जाता है, तो यह सूचित किया जाता है लेकिन कोई अन्य अनुप्रयोग समाप्त नहीं होते हैं।

एप्लिकेशन को कॉल करके हमेशा स्पष्ट रूप से रोका जा सकता है application:stop/1 । मोड के बावजूद, कोई अन्य अनुप्रयोग प्रभावित नहीं होते हैं।

क्षणिक मोड थोड़ा व्यावहारिक उपयोग का है, क्योंकि जब एक पर्यवेक्षण पेड़ समाप्त हो जाता है, तो इसका कारण normal नहीं, बल्कि shutdown