POSIX कल्पना वास्तव में अपने दांव हेज को नियंत्रित करती है जहां नियंत्रण टर्मिनल का संबंध है, और जो इसे इस प्रकार परिभाषित करता है:
- टर्मिनल को नियंत्रित करना
- टर्मिनल का जिक्र करने वाली संभवत: कई विशेष फाइलों में से कौन सा प्रश्न POSIX.1 में संबोधित नहीं किया गया है। पाथनाम
/dev/ttyएक प्रक्रिया से जुड़े नियंत्रण टर्मिनल का एक पर्याय है।
यह परिभाषा सूची में है - और यह सब वहाँ है। लेकिन जनरल टर्मिनल इंटरफ़ेस में , कुछ और कहा गया है:
एक टर्मिनल अपने नियंत्रण टर्मिनल के रूप में एक प्रक्रिया से संबंधित हो सकता है। एक सत्र की प्रत्येक प्रक्रिया जिसमें एक नियंत्रण टर्मिनल होता है, एक ही नियंत्रण टर्मिनल होता है। एक टर्मिनल अधिकतम एक सत्र के लिए नियंत्रण टर्मिनल हो सकता है। एक सत्र के लिए नियंत्रण टर्मिनल को कार्यान्वयन-परिभाषित तरीके से सत्र के नेता द्वारा आवंटित किया जाता है। यदि किसी सत्र के नेता के पास कोई नियंत्रण टर्मिनल नहीं है, और वह एक टर्मिनल डिवाइस फ़ाइल खोलता है जो पहले से ही O_NOCTTY विकल्प (ओपन () देखें) का उपयोग किए बिना सत्र से संबद्ध नहीं है, तो यह कार्यान्वयन-परिभाषित है कि क्या टर्मिनल सत्र का नियंत्रण टर्मिनल बन जाता है नेता।
एक फोर्क () फ़ंक्शन कॉल के दौरान कंट्रोलिंग टर्मिनल को एक बच्चे की प्रक्रिया द्वारा विरासत में मिला है। जब इसके साथ एक नया सत्र बनता है तो एक प्रक्रिया अपने नियंत्रण टर्मिनल को त्याग देती हैsetsid()समारोह; पुराने सत्र में अन्य प्रक्रियाएँ जो इस टर्मिनल के पास थीं क्योंकि उनके नियंत्रण टर्मिनल के पास यह जारी है। सिस्टम में अंतिम फ़ाइल डिस्क्रिप्टर के बंद होने पर (वर्तमान सत्र में है या नहीं) कंट्रोलिंग टर्मिनल के साथ जुड़ा हुआ है, यह अनिर्दिष्ट है कि क्या सभी प्रक्रियाओं में उस टर्मिनल के रूप में उनके नियंत्रण टर्मिनल के पास कोई नियंत्रण टर्मिनल नहीं है। क्या और कैसे एक सत्र के नेता नियंत्रण टर्मिनल को फिर से प्राप्त कर सकते हैं, क्योंकि नियंत्रित टर्मिनल को इस तरह से अनिर्दिष्ट किया गया है। एक प्रक्रिया अपने नियंत्रण टर्मिनल को केवल इसलिए नियंत्रित नहीं करती है कि अगर नियंत्रण के साथ जुड़े इसकी सभी फ़ाइल विवरणकर्ता बंद हो जाते हैं यदि अन्य प्रक्रियाएं इसे खोलना जारी रखती हैं।
वहाँ बहुत कुछ है जो अनिर्दिष्ट है - और ईमानदारी से मुझे लगता है कि यह समझ में आता है। जबकि टर्मिनल एक प्रमुख उपयोगकर्ता इंटरफ़ेस है, यह कुछ मामलों में सभी प्रकार की अन्य चीजें भी है - जैसे वास्तविक हार्डवेयर, या यहां तक कि एक प्रकार का प्रिंटर - लेकिन बहुत सारे मामलों में यह व्यावहारिक रूप से कुछ भी नहीं है - जैसे xtermकि सिर्फ एक एमुलेटर । वहां विशिष्ट होना मुश्किल है - और मुझे नहीं लगता कि यह वैसे भी यूनिक्स के हित में होगा, क्योंकि टर्मिनल यूनिक्स से बहुत अधिक हैं।
वैसे भी, POSIX भी सुंदर iffy है कि कैसे psव्यवहार करना चाहिए जहां शेट्टी का संबंध है।
वहाँ -aस्विच है:
- टर्मिनलों से जुड़ी सभी प्रक्रियाओं की जानकारी लिखें। कार्यान्वयन इस सूची से सत्र के नेताओं को छोड़ सकता है।
महान। सत्र के नेताओं को छोड़ा जा सकता है। यह बहुत मददगार नहीं है।
और -t:
- टर्मिनलों में दी गई टर्मिनलों से जुड़ी प्रक्रियाओं की जानकारी लिखें। आवेदन यह सुनिश्चित करेगा कि शब्दावली एक
<blank>या अल्पविराम से अलग सूची के रूप में एक तर्क है । कार्यान्वयन-परिभाषित प्रारूप में टर्मिनल पहचानकर्ता दिए जाएंगे ।
... जो एक और लेट-डाउन है। लेकिन यह XSI सिस्टम के बारे में यह कहता है:
- XSI-अनुरूप सिस्टम पर, उन्हें दो रूपों में से एक में दिया जाएगा: डिवाइस का फ़ाइल नाम (उदाहरण के लिए
tty04), या, यदि डिवाइस का फ़ाइल नाम के साथ शुरू होता है tty, तो पात्रों के बाद पहचानकर्ता tty (उदाहरण के लिए, 04) ।
यह थोड़ा बेहतर है, लेकिन एक रास्ता नहीं है। XSI सिस्टम पर भी -dस्विच है:
- सत्र के नेताओं को छोड़कर सभी प्रक्रियाओं की जानकारी लिखें।
... जो कम से कम स्पष्ट है। आप -output स्विच को ttyप्रारूप स्ट्रिंग के साथ निर्दिष्ट कर सकते हैं , लेकिन, जैसा कि आपने नोट किया है, इसका आउटपुट प्रारूप कार्यान्वयन-परिभाषित है। फिर भी, मुझे लगता है कि यह जितना अच्छा है उतना अच्छा है। मुझे लगता है कि - बहुत काम के साथ - कुछ अन्य उपयोगिताओं के संयोजन में उपरोक्त स्विच आपको एक बहुत अच्छा बॉलपार्क मिल सकता है। हालांकि काफी ईमानदार होने के लिए, मुझे नहीं पता कि यह आपके लिए कब / कैसे टूटता है - और मैं ऐसी स्थिति की कल्पना नहीं कर पाया हूं जिसमें यह होगा। लेकिन, मुझे लगता है कि अगर हम जोड़ते हैं fuserऔर findहम पथ को सत्यापित कर सकते हैं।
exec 2<>/dev/null
ctty=$(sh -c 'ps -p "$$" -o tty=' <&2)
sid=$(sh -c 'ps -Ao pid= -o tty=|
grep '"$ctty$"' |
grep -Fv "$(ps -do pid=)"' <&2)
find / -type c -name "*${ctty##*/}*" \
-exec fuser -uv {} \; 2>&1 |
grep ".*$ctty.*${sid%%"$ctty"*}"
/dev/nullसामान बस पता चलता है जब खोज subshells में से कोई भी 0,1,2 ctty से जुड़ा के किसी भी था कि यह काम कर सकता था। वैसे भी, कि प्रिंट:
/dev/pts/3: mikeserv 3342 F.... (mikeserv)zsh
अब उपरोक्त को मेरी मशीन पर पूरा रास्ता मिल गया है, और मुझे लगता है कि यह ज्यादातर मामलों में ज्यादातर लोगों के लिए होगा। मैं यह भी सोच सकता हूं कि यह विफल हो सकता है। यह सिर्फ मोटा अनुमान है।
यह संभवत: कई अन्य कारणों से विफल हो सकता है, लेकिन यदि आप एक ऐसी प्रणाली पर हैं, जो सत्र के नेता को सभी विवरणों को शेट्टी को त्यागने की अनुमति देता है और फिर भी वह किनारे पर रहता है, जैसा कि कल्पना की अनुमति देता है, तो यह निश्चित रूप से मदद करने वाला नहीं है। उस ने कहा, मुझे लगता है कि यह ज्यादातर मामलों में बहुत अच्छा अनुमान लगा सकता है।
निश्चित रूप से सबसे आसान काम अगर आप अपने शेट्टी से जुड़ा कोई भी वर्णनकर्ता है ...
tty <&2
...या इसी के समान।
psसमाधान अधिकांश प्रणालियों को कवरwhoकरता है (और अधिक मदद नहीं करता हैps), संभवतः अकेले पहचानकर्ता को संभालने के लिए थोड़ा और कोड के साथ (जैसे "04")। मैं सोच रहा था कि क्या कोई और भी पोर्टेबल समाधान था।