क्यों उपयोग करने के लिए </> आवश्यक हैं / dev / tcp

13

जब कॉल करने की कोशिश की जा रही है /dev/tcp/www.google.com/80, तो टाइप करके

/dev/tcp/www.google.com/80

बैश कहता है no such file or directory। जब ऑनलाइन अन्य लोगों के कोड को देखते हैं, तो वे सिंटैक्स का उपयोग करते हैं जैसे कि

 3<>/dev/tcp/www.google.com/80

मैंने देखा कि यह भी काम करता है:

</dev/tcp/www.google.com/80

इन प्रतीकों को बैश में कुछ चीजों को कॉल करने की आवश्यकता क्यों है?

— जॉन डो
स्रोत

2

"कॉल" से आपका क्या मतलब है? कृपया हमें बताएं कि आप क्या कर रहे हैं, जब आपको त्रुटि मिलती है। क्या आप इसे निष्पादित करने की कोशिश कर रहे हैं? यहां तक कि अगर Google का पहला पृष्ठ निष्पादन योग्य कोड था, तो भी मैं इसकी सिफारिश नहीं करूंगा।

— सीटीएल-अल्ट-डेलोर

/dev/tcp/www.google.com/80

— john

मैंने आपके प्रश्न का संपादन किया, यह कहने के लिए कि आपका क्या मतलब है।

— सीटीएल-अल्ट-डेलोर

29

क्योंकि यह शेल की एक विशेषता है (ksh की, बैश द्वारा कॉपी की गई), और शेल केवल।

/dev/tcp/...वास्तविक फाइलें नहीं हैं, शेल किसी /dev/tcp/...फ़ाइल में रीडायरेक्ट करने का प्रयास करता है और फिर उस मामले में (उस फ़ाइल को खोलने socket(...);connect(...)) के बजाय एक open("/dev/tcp/..."...)( टीसीपी कनेक्शन बनाता है ) करता है।

ध्यान दें कि इसे उसी तरह वर्तनी देना है। cat < /dev/./tcp/...या ///dev/tcp/...काम नहीं करेगा, और इसके बजाय उन फ़ाइलों को खोलने का प्रयास करेगा (जो अधिकांश प्रणालियों में मौजूद नहीं हैं और आपको एक त्रुटि मिलेगी)।

पुनर्निर्देशन की दिशा भी मायने नहीं रखती। आप का उपयोग करें 3< /dev/tcp/...या 3> /dev/tcp/...या 3<> /dev/tcp/...या यहाँ तक कि 3>> /dev/tcp/...कोई फर्क नहीं होगा, तो आप उस TCP सॉकेट से अधिक / भेजने डेटा प्राप्त करने के उस फ़ाइल वर्णनकर्ता करने के लिए दोनों पढ़ने और / से लिखने के लिए कर सकेंगे।

जब आप ऐसा करते हैं cat /dev/tcp/..., तो यह काम नहीं करता है क्योंकि catयह उसी विशेष हैंडलिंग को लागू नहीं करता है, यह open("/dev/tcp/...")हर फ़ाइल (छोड़कर -), केवल शेल (ksh, bash केवल) करता है, और केवल पुनर्निर्देशन के लक्ष्य के लिए पसंद करता है।

यह cat -विशेष रूप से संभाले गए फ़ाइल पथ का एक और उदाहरण है। ए करने के बजाय open("-"), यह सीधे फाइल डिस्क्रिप्टर 0 (स्टडिन) से पढ़ता है। catऔर कई पाठ उपयोगिताएँ ऐसा करती हैं, शेल अपने पुनर्निर्देशन के लिए नहीं है। -फ़ाइल की सामग्री को पढ़ने के लिए , आपको आवश्यकता है cat ./-, या cat < -(या cat - < -)। सिस्टम में जो नहीं है /dev/stdin, bashवह हालांकि उस (आभासी) फ़ाइल से पुनर्निर्देशन के लिए कुछ समान करेगा। जीएनयू awkके लिए एक ही करता है /dev/stdin, /dev/stdout, /dev/stderrयहां तक कि प्रणाली है कि इस तरह की फ़ाइलों जो लिनक्स की तरह सिस्टम पर कुछ आश्चर्य पैदा कर सकता है, जहां उन फ़ाइलों को अलग ढंग से व्यवहार किया है पर।

zshइसमें TCP (और Unix डोमेन स्ट्रीम) सॉकेट सपोर्ट भी है, लेकिन यह एक ztcp(और zsocket) बिल्डिंस के साथ किया गया है , इसलिए यह ksh / bash दृष्टिकोण से कम सीमित है। विशेष रूप से, यह एक सर्वर के रूप में भी कार्य कर सकता है जो ksh / bash नहीं कर सकता है। यद्यपि आप वास्तविक प्रोग्रामिंग भाषा में क्या कर सकते हैं, यह उससे कहीं अधिक सीमित है।

— स्टीफन चेज़लस
स्रोत

4

आप विचारों को भ्रमित कर रहे हैं या किसी फ़ाइल को पढ़ रहे हैं और एक कमांड निष्पादित कर रहे हैं। डेटा और निर्देश के बीच का अंतर।

Googles फ्रंट पेज एक निष्पादन योग्य कार्यक्रम नहीं है। और अगर यह होता तो इसे चलाना सुरक्षित नहीं होता।

पुनर्निर्देशन वर्ण (सहित ) <और >, एक कमांड में डेटा को निर्देशित करने के लिए उपयोग किया जाता है।

हम कर सकते हैं cat < /dev/tcp/towel.blinkenlights.nl/23हालांकि यह काम नहीं करेगा /dev/tcp/www.google.com/80क्योंकि यह पोर्ट तब तक जवाब नहीं देगा जब तक हम भेजते हैंGET / HTTP/1.0\r\n\r\n

इसलिए कोशिश करें

{
  printf >&3 'GET / HTTP/1.0\r\n\r\n'
  cat <&3
} 3<>/dev/tcp/www.google.com/80

— Ctrl-Alt-delor
स्रोत

1

यदि फ़ाइल मौजूद है तो आपको एक अलग त्रुटि मिलेगी लेकिन निष्पादन योग्य नहीं है।

— बमर