क्या lsकमांड पर सूचीबद्ध फ़ाइलों की मात्रा को सीमित करने का एक तरीका है ?
मैंने देखा है:
ls | head -4
लेकिन पाने के लिए headया tailनिष्पादित होने के लिए मुझे lsनिष्पादन समाप्त करने के लिए प्रतीक्षा करने की आवश्यकता है , और निर्देशिकाओं के साथ एक उत्साही मात्रा में फाइलें हैं जो काफी समय ले सकती हैं।
मैं एक lsकमांड निष्पादित करना चाहता हूं जो उस headकमांड का उपयोग किए बिना सीमित हो ।
जवाबों:
आपने कोशिश की है
ls -U | head -4
यह सॉर्टिंग को छोड़ देना चाहिए, जो कि शायद lsइतना लंबा समय ले रहा है।
ls -Uजरूरी नहीं है कि मुद्रण से पहले पूरी निर्देशिका पढ़ें। strace -e getdents,write ls -U > /dev/nullउदाहरण के लिए एक बड़ी निर्देशिका में प्रयास करें ।
यदि आपके संस्करण में lsफ़ाइलों को क्रमबद्ध नहीं करने का एक तरीका है, जैसे कि -UGNU ls , तो इसका उपयोग करें। कोई विकल्प नहीं है, lsपहले सभी फाइलों को पढ़ेंगे, फिर नामों को क्रमबद्ध करेंगे, फिर प्रिंट करना शुरू करेंगे।
एक और संभावना है find, चलाने के लिए , जो नामों को प्रिंट करता है क्योंकि यह उन्हें ढूंढता है।
find . -name . -o -prune | head
(ध्यान दें कि जब headसे लाइनों पर काम कर रहा है , यह मान लेता है कि फ़ाइल नाम में न्यूलाइन वर्ण नहीं हैं)।
find(जैसे कि बिजीबॉक्स या हिरलूम findया GNU के विपरीत ls -U), ऐसा लगता है कि यह प्रिंट करने के लिए शुरू करने से पहले पूरी निर्देशिका को पढ़ता है।
शायद आप के अलावा एक उपकरण की जरूरत है ls?
उदाहरण के लिए, रैंडल श्वार्ट्ज के पास बड़ी निर्देशिकाओं का उपयोग perlकरने के बारे में एक ब्लॉग प्रविष्टि है जिसमें आपकी आवश्यकताओं को पूरा करने वाले कुछ निर्माण पर कुछ संकेत हो सकते हैं।
ब्लॉग पोस्टिंग में, रान्डल बताते हैं कि दोनों lsऔर findकिसी भी छपाई से पहले सभी निर्देशिका प्रविष्टियों में पढ़ने का प्रयास करते हैं, जबकि perlवह जो समाधान प्रस्तावित करता है वह नहीं करता है।
perlशायद readdir(3)पसंद करता है lsया find। readdir(3)जीएनयू / लिनक्स के वर्तमान संस्करणों पर कम से कम getdents()सिस्टम कॉल को एक बड़ी गिनती के साथ कहते हैं (जो कि वास्तव में सिस्टम कॉल की संख्या को कम करके प्रदर्शनों का अनुकूलन करता है)। लेकिन आपके मामले में, यदि आप कम फाइलें चाहते हैं, तो ऐसा लगता है कि आपको इसके बजाय readdirBSDs getdirentries(3)या getdents(2)सिस्टम कॉल को बायपास करना होगा ।
यदि प्रदर्शन चिंता का विषय नहीं है (जैसा कि इस प्रश्न के डुप्लिकेट के रूप में बंद किया गया था), और आप lsगैर की सूची में पहली n फाइलें (आउटपुट के पहले n लाइनों के विपरीत ) सूचीबद्ध करना चाहते हैं। फ़ाइल नाम द्वारा छांटी गई छिपी हुई फाइलें zsh, आप उपयोग कर सकते हैं:
ls -ld -- *([1,4])
पहले 4 फाइलों को सूचीबद्ध करने के लिए। zshहालाँकि, निर्देशिका की पूरी सामग्री को अभी भी पढ़ेंगे, भले ही आप इसे क्रमबद्ध न करने को कहें *(oN[1,4])(ध्यान दें कि ls यह सूची भी क्रमबद्ध हो )।
शायद कम अपनी आवश्यकताओं के लिए बेहतर अनुकूल है?
ls /usr/bin | less
मेरे लिए, यह क्लासिक HDD के साथ 5 साल पुराने लैपटॉप पर तुरंत काम करता है, लेकिन सिर भी उतना ही तेज़ है।
आप lessसमय से पहले समाप्त कर सकते हैं q।
मुझे लगता है कि 1s देरी के स्रोत के बारे में आपकी धारणा गलत है, लेकिन शायद यह आपके यूनिक्स-स्वाद या आपके शेल, कम या हेड कमांड पर निर्भर करता है।
लिनक्स पर, GNU-ls के साथ,
ls -R /usr | less
मेरे लिए तुरंत आउटपुट देना शुरू कर देता है, जबकि पूरा आउटपुट अन्डर रनिंग चल रहा है - इसलिए कम शुरू होने से पहले यह निश्चित रूप से समाप्त नहीं होता है। आप जाँच कर सकते हैं, यदि आपके पास आउटपुट के आधार पर 1s या शायद अधिक की निरंतर देरी है या नहीं।
मुझे लगता है कि आपके 1s देरी का एक अलग कारण है, शायद एचडीडी सोने जा रहा है और एक जागने की आवश्यकता है?
क्या आपके पास बहुत कम फाइलों के लिए भी इतनी देरी है?
lsपरिणाम के परिणाम के साथ निष्पादित किया जाता है । मैं परिणामों को सीमित करने के लिए खुद को ls करने का एक तरीका ढूंढ रहा था।
ls -lrth | tail
ls -lrth | tail -n 10
ls -lrth | grep *.gz | tail
lsबैश पर आदेश। पाइप्ड कमांड की तरह grep, head, tailया दूसरों के बाद क्रियान्वित कर रहे हैंls
$ cut -f 1,n filename
पहली nफ़ाइलों को लाने का कार्य करेगा ।
nउन फ़ाइलों की संख्या है जिन्हें आप निकालना चाहते हैं। इतना पूरा कोड होगा:
$ ls|cut -f 1,n file
ls | cut -f 1,n fileआपके द्वारा सुझाई गई कमांड पाठ की प्रत्येक पंक्ति में पहले और nth फ़ील्ड को fileआउटपुट करेगी, और इसके आउटपुट को पूरी तरह से अनदेखा कर देगी ls। यह वह नहीं करता है जो मूल पोस्टर की आवश्यकता है।