2012-11-05 97 views
8

क्या system() कॉल कर सकते हैं die पर्ल 5 में?क्या एक पर्ल सिस्टम() कॉल कभी मर सकता है?

(दूसरे शब्दों 100% दुर्घटना सबूत एक प्रोग्राम है जो एक system() कॉल करता है, करने के लिए, में यह एक eval ब्लॉक में लपेटा किए जाने की जरूरत है, या कि पूरी तरह से पूरी तरह से अनावश्यक है?)


मुझे perldoc system में उस संभावना का एक भी उल्लेख नहीं मिला है, लेकिन सटीक "यह कॉल कभी नहीं मरता" बिल्कुल सटीक नहीं मिला।

नोट: प्रश्न यहां मूल कोर पर्ल के बारे में है, कोई autodie या कोई अन्य कस्टम मॉड्यूल जो समान प्रभाव डालेगा। साथ ही, मान लें कि ALRM सिग्नल सेट किया गया था, या उस मामले के लिए कोई अन्य कस्टम सिग्नल हैंडलर।

मुझे लगता है कि पर्ल 5 के सभी संस्करण। * वही व्यवहार करते हैं, लेकिन यदि नहीं, तो 5.8 से संबंधित एक उत्तर की सराहना की जाएगी।

+0

मैं नहीं गया और स्रोत को देखा, इसलिए मैं इसे उत्तर के रूप में पोस्ट नहीं कर रहा हूं, लेकिन अगर मैं 'सिस्टम' को स्मृति से बाहर निकलने का कोई तरीका नहीं था तो मुझे आश्चर्य होगा। – Gilles

+0

@ गिल्स - "मेमोरी से बाहर" का कारण पर्ल को कॉर्डम्प/क्रैश के बजाय "मर" जारी करना होगा? मैं बाद में मानता हूं, लेकिन न ही कुछ – DVK

+0

@ गिल्स - [अगर केवल हमारे पास एक ऐसा स्थान था जहां हम प्रोग्रामिंग प्रश्न पूछ सकते हैं ...] (http://stackoverflow.com/questions/13243637/is-there-a- मानक -तरह के लिए पर्ल-व्यवहार करते हैं-जब यह रन-आउट-ऑफ-स्मृति के लिए)। चलो देखते हैं कि एसओ ज्ञान क्या पता चला है। – DVK

उत्तर

6

जब तक स्रोत मेरी व्याख्या गलत है, यह एक संभावना की तरह लग रहा पर्ल 5.16.2 (5.8.8 भी चेक किया गया), फ़ाइल: pp_sys.c, लाइन: 4224 PP(pp_system) कोड ब्लॉक के भीतर:

if (n != sizeof(int)) 
    DIE(aTHX_ "panic: kid popen errno read, n=%u", n); 

DIEPerl_die(pTHX_ const* pat, ...) प्रलेखन के अनुसार util.c

में घोषित किया जाता है, "आतंक: बच्चा popen errno पढ़" का अर्थ है "काँटेदार बच्चे अपने errno के बारे में एक समझ से बाहर संदेश दिया"।

Explanation of panic messages in Perl:

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

+0

यह केवल तब होगा जब 1) बच्चे द्वारा निष्पादित निष्पादन() विफल रहता है और 2) बच्चा पाइप के माध्यम से माता-पिता को 4 (शायद 8) बाइट्स भेजने में असमर्थ है। – ErikR

0

system कार्यक्रम की बाहर निकलने की स्थिति देता है। इसका मतलब है, यदि प्रोग्राम क्रैश हो जाता है, तो कॉलिंग पर्ल स्क्रिप्ट जारी है (देखें system)।

फिर भी, प्रोग्राम स्वयं भी कॉलिंग स्क्रिप्ट को मार सकता है या कंप्यूटर को भी क्रैश कर सकता है। उदाहरण के लिए, लिनक्स में:

system 'killall', 'perl'; 
print "Alive\n"; 
+0

कृपया ब्रायन एग्नू को मेरी टिप्पणी देखें। यह वह नहीं है जो मैं पूछ रहा था। – DVK

1

आप उम्मीद के साथ system() कॉल कर सकते हैं कि यह एक अपवाद फेंक नहीं होंगे। इसे eval ब्लॉक में लपेटने की कोई आवश्यकता नहीं है।

+0

"उम्मीद के साथ" - क्या इसके लिए कोई तकनीकी आधार है? यदि आप j.w.r. के उत्तर को देखते हैं, तो आपका कथन पूरी तरह से गलत लगता है। – DVK

+0

मुझे यह देखने में दिलचस्पी होगी कि कितने सीपीएएन मॉड्यूल 'सिस्टम' द्वारा फेंकने वाले अपवाद को पकड़ने का प्रयास करते हैं। मुद्दा यह नहीं है कि ऐसा नहीं हो सकता है बल्कि आप आमतौर पर 'सिस्टम()' का उपयोग उम्मीद के साथ कर सकते हैं कि यह अपवाद नहीं फेंक देगा। – ErikR

0

मुझे लगता है कि आप system फ़ंक्शन के कार्यान्वयन के बारे में बात कर रहे हैं क्योंकि कॉल के माध्यम से जो कुछ भी कहा जाता है उसके विपरीत। (जाहिर है, एक बच्चे की प्रक्रिया माता-पिता के संदर्भ में die पर कॉल नहीं कर सकती है, और यहां तक ​​कि यह मानता है कि कॉल पर्ल कोड है।)

एक निश्चित उत्तर के लिए आंतरिकों के ज्ञान की आवश्यकता होगी लेकिन एक गैर-आह्वान करने का प्रयास करने के बाद -existent कार्यक्रम मर नहीं है, मैं किसी और कि कुछ भी कभी होगा कल्पना नहीं कर सकते, या तो:

स्रोत::

system('abcd');  # 'abcd' is not recognized... [Win32 message] 
say "I'm not dead."; # always prints 
+0

"मुझे लगता है कि आप सिस्टम फ़ंक्शन के कार्यान्वयन के बारे में बात कर रहे हैं क्योंकि कॉल के माध्यम से जो भी कहा जाता है उसके विपरीत।" - स्रोत के पढ़ने से – DVK

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

  • कोई संबंधित समस्या नहीं^_^