2009-02-04 8 views
5

कहें कि विकास के तहत किसी एप्लिकेशन के लिए कुछ कार्यक्षमता की आवश्यकता है जिसे कमांड लाइन प्रोग्राम या लाइब्रेरी का उपयोग करने के लिए सिस्टम कॉल करके हासिल किया जा सकता है। मान लीजिए दक्षता कोई मुद्दा नहीं है, क्या पुस्तकालय का उपयोग करने के बजाय प्रोग्राम को सिस्टम कॉल करने के लिए यह बुरा अभ्यास है? ऐसा करने के नुकसान क्या हैं?क्या लाइब्रेरी फ़ंक्शन का उपयोग किए जाने पर सिस्टम() फ़ंक्शन का उपयोग करना बुरा व्यवहार है? क्यूं कर?

चीजों को और अधिक ठोस बनाने के लिए, इस परिदृश्य का एक उदाहरण एक ऐसा एप्लीकेशन होगा जिसे वेब सर्वर से फ़ाइल डाउनलोड करने की आवश्यकता होती है, या तो curl प्रोग्राम या libcURL लाइब्रेरी का उपयोग इस के लिए किया जा सकता है।

उत्तर

10

जब तक आप केवल एक ओएस के लिए कोड नहीं लिख रहे हैं, तो यह जानने का कोई तरीका नहीं है कि आपका सिस्टम कॉल भी काम करेगा या नहीं। सिस्टम अपडेट या ओएस अपग्रेड होने पर क्या होता है?
कभी भी एक सिस्टम कॉल का उपयोग करें यदि एक ही कार्य करने के लिए लाइब्रेरी है।

+2

बस यह शाम मैं अपने कुछ छोटे पर्ल उपयोगिता कार्यक्रमों के माध्यम से चला गया और फाइल :: कॉपी - नया संस्करण के साथ कॉपी कमांड को सिस्टम कॉल का उपयोग करके बदल दिया गया है और विंडोज़ की बजाय मेरे सभी प्लेटफॉर्म पर काम करता है। – Sol

2

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

3

मैं निर्भरता मुद्दे की वजह से पुस्तकालयों को प्राथमिकता देता हूं, अर्थात् निष्पादन योग्य तब नहीं हो सकता जब आप इसे कॉल करते हैं, लेकिन लाइब्रेरी होगी (माना जाता है कि बाहरी लाइब्रेरी संदर्भों को आपकी प्लेटफ़ॉर्म पर प्रक्रिया शुरू होने पर ध्यान दिया जाता है)। दूसरे शब्दों में, पुस्तकालयों का उपयोग सिस्टम कॉल की तुलना में अधिक वातावरण में अधिक स्थिर, अनुमानित परिणाम की गारंटी देगा।

3

खाते में ध्यान देने के कई कारक हैं। एक महत्वपूर्ण बात यह है कि बाहरी प्रोग्राम उन सभी प्रणालियों पर मौजूद होगा जहां आपका सॉफ़्टवेयर स्थापित है। यदि कोई संभावना है कि यह गायब हो जाएगा, तो हो सकता है कि यह आपके प्रोग्राम के अंदर करना बेहतर हो।

इसके खिलाफ वजन, आप मान सकते हैं कि आपके प्रोग्राम में लोड किया गया अतिरिक्त कोड निषिद्ध है - आपको अपने आवेदन के इस तरह के कभी-कभी उपयोग किए जाने वाले हिस्से के लिए कोड ब्लोट की आवश्यकता नहीं है।

सिस्टम() फ़ंक्शन सुविधाजनक, लेकिन खतरनाक है, कम से कम नहीं क्योंकि यह आमतौर पर एक खोल का आह्वान करता है। यूनिक्स पर, फोर्क() और exec() सिस्टम कॉल के माध्यम से आप प्रोग्राम को अधिक सीधे कॉल करने से बेहतर हो सकते हैं। [ध्यान दें कि system() फ़ंक्शन को संयोग से कॉल करने से सिस्टम कॉल बहुत अलग है!] ओटीओएच, आपको अपने प्रोग्राम में सभी खुले फ़ाइल डिस्क्रिप्टर को बंद करने के बारे में चिंता करने की आवश्यकता हो सकती है - खासकर यदि आपका प्रोग्राम किसी प्रकार का डिमन चल रहा है अन्य उपयोगकर्ता; यदि आप विशेष विशेषाधिकारों का उपयोग नहीं कर रहे हैं, तो यह एक समस्या से कम है, लेकिन यह अभी भी एक अच्छा विचार है कि आप जिस भी कार्यक्रम का इरादा नहीं रखते हैं, उसे आमंत्रित कार्यक्रम न दें। आपको fcntl() सिस्टम कॉल और FD_CLOEXEC ध्वज को देखने की आवश्यकता हो सकती है।

आम तौर पर, यदि आप अपने कार्यक्रम में कार्यक्षमता बनाते हैं, तो यह चीजों पर नियंत्रण रखना आसान है, लेकिन यह एक मामूली निर्णय नहीं है।

1

सिस्टम कॉल सुरक्षित रूप से करने के लिए बहुत कठिन हैं।

सभी प्रकार के मजाकिया पात्रों को तर्क पारित करने के लिए सही ढंग से एन्कोड किया जाना आवश्यक है, और एन्कोडिंग के प्रकार मंच या यहां तक ​​कि कमांड के संस्करण से भिन्न हो सकते हैं। इसलिए सिस्टम कॉल करने में जिसमें कोई भी उपयोगकर्ता डेटा शामिल है, बहुत सारी सैनिटी-जांच की आवश्यकता होती है और गलती करना आसान होता है।

1

हाँ, ऊपर वर्णित अनुसार, सिस्टम कॉल (जैसे fcntl() और open()) और सिस्टम() कॉल के बीच अंतर को ध्यान में रखें।:)

एक सी प्रोग्राम प्रोटोटाइप के शुरुआती चरणों में, मैं अक्सर पॉपन() का उपयोग करके फ़ाइलों के हेरफेर के लिए grep और sed जैसे प्रोग्रामों को बाहरी कॉल करता हूं। यह सुरक्षित नहीं है, यह सुरक्षित नहीं है, और यह निश्चित रूप से पोर्टेबल नहीं है। लेकिन यह आपको जल्दी से जाने की अनुमति दे सकता है। यह मेरे लिए मूल्यवान है। यह मुझे कार्यक्रम के वास्तव में महत्वपूर्ण कोर पर ध्यान केंद्रित करने देता है, आमतौर पर कारण मैंने पहली बार सी का उपयोग किया था।

उच्च स्तर की भाषाओं में, आप बेहतर एक अच्छा कारण होगा। :)

0

या तो करने के बजाय, मैं इसे यूनिक्स कर दूंगा और कमांड लाइन तर्क और stdin का उपयोग करके अपने ऐप के चारों ओर एक स्क्रिप्ट ढांचे का निर्माण करूंगा।

0

अन्य ने अच्छे अंक (विश्वसनीयता, सुरक्षा, सुरक्षा, पोर्टेबिलिटी इत्यादि) का उल्लेख किया है - लेकिन मैं एक और फेंक दूंगा। प्रदर्शन। आम तौर पर लाइब्रेरी फ़ंक्शन को कॉल करने के लिए कई बार तेज़ होता है या फिर एक नया थ्रेड भी शुरू होता है, फिर यह एक पूरी नई प्रक्रिया शुरू करना है (और फिर भी आपको इसे निष्पादन की सही जांच/सत्यापित करना होगा और इसके आउटपुट को पार्स करना होगा!)

संबंधित मुद्दे