.Test के बजाय .test के रूप में निष्पादित करें


26

यह मानकर कि मैं निष्पादन योग्य फ़ाइल के समान फ़ोल्डर में हूं, मुझे इसे निष्पादित करने के लिए इसे टाइप करने की आवश्यकता होगी:

./file

मुझे टाइप करने की ज़रूरत नहीं है /, क्योंकि /मेरे लिए टाइप करना मुश्किल है।

क्या किसी फ़ाइल को निष्पादित करने का एक आसान तरीका है? आदर्श रूप में बस कुछ सरल वाक्य रचना:

.file

या कुछ और लेकिन /वहाँ चरित्र सम्मिलित करने की तुलना में आसान है ।

शायद /binनिर्देशिका में कुछ डालने या दुभाषिया के लिए एक उपनाम बनाने का कोई तरीका है , ताकि मैं उपयोग कर सकूं:

p file

9
शायद स्वैप / एक और कुंजी के साथ xmodmap का उपयोग कर रहा है? इसलिए कम से कम टाइप करना आसान है
लड़के

26
एक तरफ ध्यान दें के रूप में, /प्रयोग किया जाता है बड़े पैमाने पर मोटे तौर पर एक निर्देशिका विभाजक के रूप में, यूनिक्स में। आप शायद इसे टाइप करने का एक आसान तरीका खोजने से बेहतर हैं।
क्राइसिस -ऑन स्ट्राइक-

7
@RossPresser यह सवाल बहुत कम समझ में आता है। और ./ फ़ाइल की शुरुआत में तकनीकी कारणों से दो पूरी तरह से अलग अर्थ हैं जो किसी भी शुरुआती को जानना चाहिए। /लोगों के विशाल बहुमत के लिए टाइप करना मुश्किल नहीं है, और अगर ओपी में चोट है जो इसे रोकता है, तो उन्हें वैकल्पिक कीबोर्ड लेआउट पर विचार करना चाहिए, क्योंकि ऐसा कोई तरीका नहीं है जिससे वे /टर्मिनल में रहते हुए पूरी तरह से बच सकें ।
JFA

1
@ जेएफए महाद्वीपीय यूरोप के साथ-साथ दक्षिण अमेरिका में इस्तेमाल किए जाने वाले कीबोर्ड लेआउट्स का अधिकांश भाग /शिफ्ट -7 में रखा गया है, जो बिना किसी चोट के भी तुलनात्मक रूप से कठिन है।
नाइट्रो 2k01

6
इतिहास संपादित करें: " केंट नेटवर्क इंटरफ़ेस को पोर्ट 22 पर ssh के माध्यम से एक दूरस्थ होस्ट के माध्यम से सभी इंटरनेट प्रश्नों को बनाने का निर्देश क्यों दिया जाए। " ere_ "
Derek 會 功夫

जवाबों:


35

यह "जोखिम भरा" हो सकता है लेकिन आप बस कर सकते हैं। अपने पेट में

जैसा कि दूसरों में कहा गया है, यह खतरनाक हो सकता है इसलिए हमेशा सुनिश्चित करें। शुरुआत के बजाय पथ के अंत में है।


1
वास्तव में यह न देखें कि यह "जोखिम भरा" कैसे है: मेरा रास्ता लिनक्स से बहुत पहले से है, और यह कभी भी मामूली समस्या नहीं हुई।
jamesqf

21
@jamesqf यह जोखिम भरा है क्योंकि यदि आप cdएक ऐसी निर्देशिका में हैं जो विश्व-योग्य है और एक कमांड का उपयोग करने का प्रयास करते हैं जो आपके मार्ग में नहीं है, तो आप एक (संभवतः दुर्भावनापूर्ण) निष्पादन योग्य नाम उसी नाम से निष्पादित कर सकते हैं जिसे किसी ने उस पथ पर लिखा था। यह बहुत बुरा है अगर आप .अपने रास्ते की शुरुआत में डालते हैं । lsयदि आप lsउस निर्देशिका में कॉल करने का प्रयास करते हैं तो उस स्थिति में, एक दुर्भावनापूर्ण निष्पादन योग्य नाम निष्पादित किया जाएगा ।
bytesized

2
उपरोक्त कारणों के लिए, कृपया इससे बचें। pआदेश बेहतर होगा।
गुइडो

11
@jamesqf जब यह "आपका" सिस्टम है, और केवल आप इसका उपयोग करते हैं, तो यह इतना बुरा नहीं है। समस्या आती है (और कई वर्षों में कई यूनिक्स व्यवस्थापक को हटा दिया है) बहु-उपयोगकर्ता प्रणाली पर। एक साथ .के शुरू में PATH, करने के लिए सभी एक दुर्भावनापूर्ण उपयोगकर्ता की जरूरत है एक नकली ड्रॉप है ls"कुछ अजीब पर देखो" करने के लिए अपने निर्देशिका में कमान और व्यवस्थापक को मनाने और वे रूट पहुँच मिल गया है।
ट्रिपहाउंड

1
अच्छा समाधान, हालांकि यह काम नहीं करेगा यदि फ़ाइल का नाम होता है test, जैसा कि प्रश्न के शीर्षक में है (चूंकि testएक शेल निर्मित है, और संभवतः आपके $PATHपहले से कहीं मौजूद है )।
पीलेतन्फ़िल

71

../कम से कम आधुनिक बैश गोले में ऑटो- टाइप (टाइप .और प्रेस Tab) करें, इसलिए आपको एक जटिल या असुरक्षित (जैसे PATHसंशोधन) समाधान का उपयोग नहीं करना चाहिए ।

यदि यह स्वतः पूर्ण नहीं होता है, तो आपको "बैश-समापन" पैकेज स्थापित करने की आवश्यकता हो सकती है।


क्या आपको यकीन है? .कई पूर्ण उम्मीदवार हैं: .(वर्तमान dir), ..(पैरेंट dir), .कमांड (जो बैश एक गैरमानक उर्फ ​​प्रदान करता है source) और किसी भी dotfiles के लिए मौजूद है। हो सकता है कि bash-completionपैकेज इस पर ध्यान न दे; मुझे यह अटपटा कष्टप्रद लगता है (जैसे कि makeकमांड लाइन में dir नामों को टैब-पूर्ण करना असंभव बना देता है और आम तौर पर निहित नियमों से भरे मेकअप के साथ भयानक होता है) इसलिए मैं हमेशा इसे शुद्ध करता हूं।
आर ..

3
मैंने इसकी कोशिश की, और हाँ, यह इस तरह से ऑटो-कम्प्लीट करता है। लगभग हर मामले में एक नियमित उपयोगकर्ता जो चाहेगा: मुझे नहीं लगता कि मैंने कभी ऐसा डॉटफ़ाइल देखा है जो निष्पादन योग्य होना चाहिए, एक उपनिर्देशिका में कुछ चलाना एक मूल निर्देशिका में कुछ चलाने की तुलना में बहुत अधिक सामान्य है, और आईएमओ यह करता है लानत है अच्छा makeलक्ष्य खोजने का काम ।
l0b0

3.2 बैश के साथ यह स्वत: पूर्ण नहीं है। यह बाश 4 म नया हो सकता है?
कैलिमा

2
@ कैलीमो बैश-समापन के हाल के संस्करणों में अधिक संभावना है। यह मूलभूत परिवर्तन से बहुत दूर है।
l0b0

42

या .. शायद दुभाषिया को bashrc फ़ाइल में एक उपनाम दे रहा है और फिर बस

   p  file

ऐसे समारोह को लिखना संभव है:

p() {
 ./"$@"
}

अपने में ~/.bashrc । तो आप के p app argumentsबजाय चलाने में सक्षम हो जाएगा ./app arguments। यह समाधान स्क्रिप्ट और बायनेरिज़ सहित किसी भी प्रकार के निष्पादन योग्य के लिए काम करता है।

"$@"समारोह में पारित तर्कों की उचित रूप से उद्धृत सूची में विस्तार होता है (ग्लोब या चर विस्तार से सभी विशेष वर्णों को संरक्षित करना), और, जैसा कि @Scott ने बताया, उनमें से पहले एक को प्रस्तुत करने के लिए bashपर्याप्त चतुर है ./, बाकी को संरक्षित करना।


हालांकि यह एक अन्य कमांड के तहत ऐप चलाने के लिए कम सामान्य है, जैसे strace -f p appसिस्टम कॉल किए गए, या $(which time) p appयह देखने के लिए कि इसमें कितना समय लगता है। pएक निष्पादन योग्य स्क्रिप्ट के रूप में मैं इन दो विशिष्ट उदाहरणों से बेहतर काम करूंगा। न तो समाधान के साथ काम कर सकता है ldd p app, यद्यपि एक पूर्ण पथ की आवश्यकता में ldd भी भिन्नता है, शायद इस तरह के कारणों के लिए।
sourcejedi

हां, किसी ऐसे तरीके से प्रतिस्थापित p app argsकरना ./app argsजो किसी के लिए अदृश्य हो, उसे किसी प्रकार के प्रीप्रोसेसर के माध्यम से पाइपिंग शेल इनपुट की आवश्यकता होगी और जब अनपेक्षित स्थान पर प्रतिस्थापन होता है तो सभी प्रकार के मज़े का कारण होगा :)
aitap

1
इस मामले में, क्या कोई उद्धरण नहीं होना चाहिए $@? अन्यथा यह सिर्फ एक बड़ा तर्क कार्यक्रम को पारित करेगा।
क्रॉल्टन

7
@ किरोलन नंबर $@एक सरणी है। जब भीतर विस्तार किया जाता है ", तो प्रत्येक पैरामीटर एक अलग शब्द तक फैलता है। $*जिस तरह से आप सोच रहे हैं वैसा ही व्यवहार करता है।
8bittree

3
मुझे विश्वास है कि आपने इसे अनावश्यक रूप से जटिल बना दिया है, और p() { ./"$@"; }आपको इसकी आवश्यकता है।
स्कॉट

11

आप .अपने $PATHजैसे में जोड़कर अपने पास रख PATH=$PATH:.सकते हैं /etc/profile, इस तरह से आप fileबस लिखकर निष्पादित कर सकते हैं file, जब तक कि यह आपके पथ के किसी अन्य फ़ोल्डर में न हो (जैसे /usr/bin/)। ध्यान दें कि यह आमतौर पर एक अच्छा विचार नहीं है।

यह बुरा क्यों है: यह कहें कि आप ऐसी स्थिति में हैं जहां आप किसी निर्देशिका की सामग्री पर पूरी तरह भरोसा नहीं करते हैं - आपने इसे कहीं से डोडी में डाउनलोड किया है और आप इसे चलाने से पहले इसकी जांच करना चाहते हैं, या आप कुछ मदद कर रहे हैं उपयोगकर्ता उनकी होम निर्देशिका में देख रहे हैं, आदि। आप निर्देशिका को सूचीबद्ध करना चाहते हैं, इसलिए आप एलएस टाइप करने की कोशिश करते हैं, लेकिन उफ़, आप एक टाइपो बनाते हैं, और इसके बजाय टाइपिंग स्ल समाप्त हो गया है। इस दुर्भावनापूर्ण निर्देशिका के लेखक ने इस बात की आशंका जताई है और इसमें एक शेल स्क्रिप्ट डाली है जिसे "sl" कहा जाता है, जो 'rm -rf --no-preserve-root /' (या कुछ और दुर्भावनापूर्ण है जैसे रूटकिट स्थापित करना)।

(स्पष्टीकरण के लिए @Muzer धन्यवाद)


13
हालाँकि मैं पूरे दिल से मानता हूँ, यह शायद समझ में नहीं आ रहा है कि यह एक अच्छा विचार क्यों नहीं है।
यम्बर्ट

16
यह बुरा क्यों है: यह कहें कि आप ऐसी स्थिति में हैं जहां आप किसी निर्देशिका की सामग्री पर पूरी तरह भरोसा नहीं करते हैं - आपने इसे कहीं से डोडी में डाउनलोड किया है और आप इसे चलाने से पहले इसकी जांच करना चाहते हैं, या आप कुछ मदद कर रहे हैं उपयोगकर्ता उनकी होम निर्देशिका में देख रहे हैं, आदि। आप निर्देशिका को सूचीबद्ध करना चाहते हैं, इसलिए आप एलएस टाइप करने की कोशिश करते हैं, लेकिन उफ़, आप एक टाइपो बनाते हैं, और इसके बजाय टाइपिंग स्ल समाप्त हो गया है। इस दुर्भावनापूर्ण निर्देशिका के लेखक ने इस बात की आशंका जताई है और इसमें एक शेल स्क्रिप्ट डाली है जिसे "sl" कहा जाता है, जो 'rm -rf --no-preserve-root /' (या कुछ और दुर्भावनापूर्ण है जैसे रूटकिट स्थापित करना)।
मुज़ेर

2
वर्थ ने समझाया कि यदि वर्तमान निर्देशिका $ PATH की शुरुआत में है, तो इसके बजाय, हमलावर सिर्फ ls या अन्य सामान्य आदेशों को ओवरराइड कर सकता है
Délisson Junio

@Muzer Huuuge टिनफ़ोइल टोपी यहाँ।
सोमब्रेरो चिकन

4
@GillBates यह उस तरह की चीज है जिसे आपको एक sysadmin के रूप में सावधान रहने की आवश्यकता होगी, जिसे वास्तविक और संभावित रूप से दुर्भावनापूर्ण उपयोगकर्ताओं, या किसी ऐसे व्यक्ति से निपटना होगा जो किसी जीवित व्यक्ति के लिए संदिग्ध अभिलेखागार का विश्लेषण करता है। अगर उनमें से कोई भी लागू नहीं होता है, तो मैं आपसे सहमत हूं। मुझे अभी भी नहीं लगता कि यह एक अच्छी आदत है, हालांकि, क्योंकि आप कभी नहीं जानते कि आपकी परिस्थितियां कब बदल जाएंगी, आपको इनमें से एक काम मिलेगा, और आप अपने आप को असुरक्षित व्यवहार पर भरोसा करने के लिए प्रशिक्षित होने के लिए खुद को शाप देंगे; )
मुज़ेर

10

आप दुभाषिया को बुला सकते हैं, उदाहरण के लिए

bash test

इस स्थिति में, स्क्रिप्ट तब भी चलेगी, जब उसके पास न तो कोई शेबंग रेखा हो (जैसे #!/bin/bash) और न ही निष्पादन योग्य बिट। इसे चलाने के लिए आपको सही दुभाषिया जानना होगा। यदि आप सही इंटरप्रेटर कहते हैं, तो सुनिश्चित करने के लिए आप पहले फ़ाइल की शेबंग लाइन पढ़ सकते हैं, उदाहरण के लिए, शेबंग लाइन

#!/usr/bin/env python3

आप फोन करेंगे

python3 test

7
दुभाषिया सिर्फ कोड की व्याख्या करते हैं, वे बाइनरी फ़ाइलों को नहीं चलाएंगे
मैक कर्नेल

यह उत्तर कुछ हद तक तर्कसंगत है क्योंकि शायद दुभाषिया को बैश आर्क फ़ाइल में एक उपनाम दिया जा सकता है।

5
@ मैक कर्नेल अच्छा बिंदु, यह केवल तभी काम करता है जब कोई दुभाषिया हो, संकलित निष्पादन के लिए नहीं
ज़ना

2
संकलित निष्पादकों के लिए एक दुभाषिया है:/lib/ld.so
दिमित्री कुद्रियात्सेव

7

जहां तक ​​मुझे पता है, इसे प्राप्त करने का कोई तरीका नहीं है जब तक कि आप फ़ाइल को एनवी पथ में शामिल नहीं करते हैं, इसलिए आप इसे केवल टाइप कर सकते हैं: file

.fileकाम नहीं करेगा क्योंकि यह एक अलग फ़ाइल नाम है। यह एक फाइल है जिसे कहा जाता है .fileऔर नहीं ./file

मुझे लगता है कि स्लैश आपके लिए टाइप करना मुश्किल हो सकता है क्योंकि गैर-अंग्रेजी लेआउट, हो सकता है? उस स्थिति में, मेरे साथ भी ऐसा होता है, इसलिए मैं अक्सर अपने कीबोर्ड लेआउट को विंडोज में Alt + Shift दबाकर अंग्रेजी में स्वैप करता हूं (मैं ssh से लिनक्स का उपयोग करता हूं)


7

लोगों ने जोड़ने .का सुझाव दिया है PATH, जो खतरनाक है क्योंकि यह एक जोखिम पैदा करता है कि आप गलती से विश्व-कुख्यात निर्देशिका में लगाए गए दुर्भावनापूर्ण कार्यक्रम चलाएंगे। लेकिन, यदि आपके पास कुछ निर्देशिकाओं में निष्पादन योग्य कार्यक्रम हैं जो आपके पास हैं और केवल आपके द्वारा ही योग्य हैं, तो यह सुरक्षित है (काफी सुरक्षित?) उन निर्देशक (ies) को PATHएक पंक्ति में जोड़कर, जैसे

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

आपकी ~/.bashrcफ़ाइल पर। बेशक इसका मतलब है कि आप उन निर्देशिकाओं में से किसी एक प्रोग्राम को फाइलसिस्टम में कहीं से भी चला सकते हैं। उदाहरण के लिए, आप cd /etcटाइप कर सकते हैं foo, और यह चलेगा ~/dev/myprog1/foo। यह छोटी सी खामी है कि आप एक से अधिक निर्देशिकाओं में एक ही नाम से कार्यक्रम नहीं कर सकते हैं। विशेष रूप से, यदि आपके पास foo दोनों में प्रोग्राम हैं ~/dev/myprog1और ~/dev/myprog2, आप एक पथ को निर्दिष्ट करने के अलावा दूसरा नहीं चला पाएंगे। इसी तरह अगर आपके पास है ~/dev/myprog1/cat- लेकिन आप क्यों करना चाहते हैं?


एक और दृष्टिकोण, यदि आपके पास कुछ कार्यक्रम हैं जो आप इसके साथ करते हैं, तो उनके लिए उपनाम परिभाषित करना है:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

या आप उपनामों को कॉल कर सकते हैं .gizmoऔर .gonzo यदि आप पाते हैं कि अधिक सहज।

वास्तव में, यह एक हद तक, .आपके में डाल के रूप में एक ही सुरक्षा जोखिम है PATH। यदि कोई दुर्भावनापूर्ण उपयोगकर्ता .bashrcआपके उपनामों को पढ़ सकता है और देख सकता है, तो वह मैलवेयर नाम से gizmoऔर gonzoयादृच्छिक निर्देशिकाओं को इस आशा में रख सकता है कि आप इसे चलाएंगे। इन उपयोगों को पूर्ण पथ बनाने के लिए बेहतर है:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

वैसे, आपको एक निष्पादन योग्य नामकरण से बचना चाहिए test, क्योंकि यह एक शेल बिल्ड कमांड है, और आप केवल पथ या किसी अन्य चाल को निर्दिष्ट करके उस नाम से एक प्रोग्राम चला सकते हैं।


वैकल्पिक रूप से आप एक नुस्खा बना सकते हैं (यदि आप मेकफाइल्स का उपयोग करते हैं) और करते हैं make gizmoया करते हैं make gonzo
इहो

मुझे क्षमा करें, लेकिन मुझे यकीन नहीं है कि मैं समझता हूं कि यह कैसे प्रश्न या मेरे उत्तर से संबंधित है। क्या आप यह सुझाव दे रहे हैं कि ओपी Makefileप्रत्येक निर्देशिका में ऐसा बनाता है , जैसे दौड़ने सेmake gizmo समाप्त होने वाली क्रियाएं gizmo? (१) ऐसा लगता है कि यह pकार्य के रूप में एक ही काम करने का एक अजीब तरीका है , सवाल में सुझाया गया है, शुरू में व्हाट्सएप द्वारा लागू किया गया था , और स्कॉट द्वारा परिष्कृत किया गया था। (२) क्या आप इस तरह से दलीलें पास कर सकते हैं? ISTM जो make gizmo arg1 arg2इसके बराबर है make gizmo; make arg1; make arg2
जी-मैन का कहना है कि 'मोनिका की बहाली'

1
(1) शायद मेरी धारणा गलत है, लेकिन यह मेरे लिए स्पष्ट नहीं है कि ओपी चाहता है ./कि हर निर्देशिका में उपयोग से बच जाए । मेरे दिमाग में, वह कुछ विकसित कर रहा है और सिर्फ उत्पादित कार्यक्रम को चलाने की जरूरत है ./file। मैं वास्तव में किसी अन्य परिदृश्य के बारे में नहीं सोच सकता, जहां किसी को अक्सर एक स्थानीय फ़ाइल चलाने की आवश्यकता होती है और अगर वह इसे अक्सर नहीं चला रहा है तो वह सवाल पूछने से परेशान नहीं होगा (उसने कहा कि मुश्किल नहीं असंभव ) (2) वास्तव में नहीं, लेकिन आप नुस्खा में तर्क पारित कर सकते हैं।
इहो

(१) ठीक है, मुझे लगता है कि हम सहमत हो सकते हैं कि ओपी की प्रेरणा और उसके प्रश्न का दायरा अस्पष्ट है। (२) लिंक के लिए धन्यवाद।
जी-मैन का कहना है कि 'मोनिका' बहाल

3

व्याख्याताओं के बारे में ज़न्ना के उत्तर पर विस्तार करने के लिए (क्षमा करें, टिप्पणी के लिए कोई प्रतिनिधि नहीं): देशी निष्पादकों (उर्फ बाइनरी ईएलएफ फ़ाइलों) के लिए एक "दुभाषिया" डायनेमिक लोडर ( ld.so) है, लेकिन यह आम तौर पर आपके द्वारा इच्छित वाक्यविन्यास को नहीं समझता है।

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

(यह भी, जब तक कि आप ld.soअपने मार्ग पर नहीं चलें, तब भी आपको /s लिखना होगा )


यह लिनक्स-विशिष्ट है, है ना? क्या आप इसे और अधिक समझा सकते हैं, यह क्यों काम करता है? मुझे लगा कि (लिनक्स) कर्नेल पार्सिंग करेगा और तय करेगा कि बाइनरी को कैसे और कैसे चलाया जाए, यही binfmt_miscहै।
phk

2
@phk फ़ाइल लिनक्स-विशिष्ट है, लेकिन एक गतिशील लिंकर / लोडर की अवधारणा नहीं है। उदाहरण के लिए, FreeBSD का अपना बहुत बड़ा हिस्सा है /libexec/ld-elf.so.1। लिनक्स पर, यह "बाइनरी चलाने के तरीके को तय करने" के रूप में सरल नहीं है: binfmt_miscजादू संख्याओं (ईएलएफ, शेंग स्क्रिप्ट, सीआईएल) द्वारा फ़ाइल के प्रारूप का पता लगाता है। उसके बाद, binfmt_elfहैंडलर कहा जाता है। यह ELF हेडर और सेक्शन को पार्स करता है; .interpअनुभाग में गतिशील लोडर का पथ शामिल है; यह लोडर कर्नेल द्वारा शुरू किया गया है, रिलोकेशन करता है, और कूदता है _start। FreeBSD पर (दूसरों के बारे में निश्चित नहीं) कोई द्वैध नहीं है, लेकिन सिद्धांत +/- समान है।
बेकाबू किया

1
@phk क्यों यह काम करता है - के ld.soपास नहीं है .interpऔर इसे सांख्यिकीय रूप से जोड़ा गया है, जिसका अर्थ है कि इसे अपने बाहरी प्रतीकों को हल करने और पुनर्वास गणित करने के लिए किसी अन्य गतिशील लिंकर / लोडर की आवश्यकता नहीं है।
बेच दिया

ISTR Solaris के पास भी इसके बराबर कुछ है।
जी-मैन '

3

अगर हमें चीजों को कॉन्फ़िगर करने की अनुमति है

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

अधिकांश आधुनिक डिस्ट्रो में $ PATH में ~ / .Local / bin पहले से ही शामिल है ( यदि आपका नहीं है तो export PATH="$HOME/.local/bin:$PATH"अपने साथ जोड़ें ~/.profile)। तब आप x fileचलाने के लिए उपयोग कर सकते हैं ./file

एक .कमांड को परिभाषित करने की कोशिश मत करो । वर्तमान शेल में कमांड . scriptपहले से ही चलता scriptहै। यह scriptवर्तमान शेल के लिए पर्यावरण चर को परिभाषित करने की अनुमति देता है।


3
मुझे लगता है कि इसमें एक अच्छा सुझाव हो सकता है, लेकिन इसमें से कोई भी स्पष्टीकरण नहीं है। मैं इसे काम कर सकता था, लेकिन एक अनुभवहीन उपयोगकर्ता के पास कोई मौका नहीं होगा।
IMSoP

$ 1 को स्थानांतरित करने की कोई आवश्यकता नहीं है। बस exec "$@"
रीइन्टीरियरपोस्ट

$ (ln -s /bin/ls my-ls && exec my-ls) # bash: exec: my-ls: not found
sourcejedi

(१) कोई जरूरत नहीं है shift $1; बस exec ./"$@"। (2) चूंकि आप एक शेल स्क्रिप्ट के बारे में बात कर रहे हैं, यह लोगों को .कमांड को परिभाषित न करने की सलाह देने के लिए थोड़ा व्यर्थ / भ्रामक है , क्योंकि यह एक फ़ाइल नामक नाम बनाना असंभव है .। (यह संभव है, और बहुत ही असावधान है, जिसे अलियास या शेल फ़ंक्शन कहा जाता है .।)
स्कॉट

1

यदि हमें सहायक स्क्रिप्ट बनाने की अनुमति है, तो आप एक सहायक बना सकते हैं जो PATH में Pwd जोड़ता है, फिर चलाएं

. pathhelper    #adds pwd to path
file            #now it can be run without ./

यह जोड़ने से बचता है "।" पथ के लिए और हर रास्ते के साथ अपने .profile प्रदूषण आप कुछ बिंदु पर कुछ में चलाने के लिए चाहते हो सकता है।

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

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

लेकिन मुझे लगता है कि अगर आप इसके साथ भागना चाहते थे तो आप हैक कर सकते थे pushdऔर popdइसलिए वे बिना सबस्क्रिप्शन लिए ही रास्ते में बदलाव कर सकते हैं जो अन्य बदलावों को खो देगा।

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(आप ऐसा नहीं कर सकते cdक्योंकि इसमें एनालॉग नहीं है popd।)

आप केवल पुश और पॉप प्रविष्टियां दर्ज करने के लिए सहायकों की एक समर्पित जोड़ी भी बना सकते हैं। वास्तव में क्या काम करता है यह आपके उपयोग पैटर्न पर निर्भर करता है।


असल में, आप इसमें कुछ कर सकते हैं cd, लेकिन यह आगे भी है: एक फ़ाइल बनाएं .dircmds, और स्विच करने से पहले अनुपलब्ध सही cdमें परिभाषित कमांड बनाने के लिए हैक करें ./.dircmdsऔर स्विच करने के बाद उपलब्ध हैं।
ShadSterling

-1

. script.shजब तक आप जिस स्क्रिप्ट को निष्पादित करना चाहते हैं, तब आप सिंटैक्स का उपयोग कर सकते हैं ।

आप दुभाषिया के साथ उपसर्ग भी कर सकते हैं, जैसे श या बैश। उदाहरण:bash script.sh


8
. script.shयदि स्क्रिप्ट में विराम होता है exit, तो अप्रत्याशित प्रभाव होते हैं जैसे कि यदि यह PATH को "अस्थायी रूप से" पुनर्परिभाषित करता है; यह केवल आपके वर्तमान शेल के लिए स्क्रिप्ट के लिए भी काम करता है
sourcejedi

@sourcejedi के संबंध में exitआप इसे कोष्ठक के अंदर रख सकते हैं, यानी एक उपधारा, लेकिन सच है, यह अभी भी केवल उसी शेल में स्क्रिप्ट के लिए होगा।
phk

सवाल कहता है "एक निष्पादन योग्य फ़ाइल"। ये द्विआधारी निष्पादन योग्य के लिए काम नहीं करेंगे; केवल एक स्क्रिप्ट के लिए। और आपका दूसरा पैराग्राफ ज़न्ना के उत्तर को दोहराता है
स्कॉट

ठीक है, मेरा बुरा, मैं ज्यादातर मारना और बैश सामान करना चाहता हूं, इसलिए मैंने मान लिया कि हम बैश स्क्रिप्ट के बारे में बात कर रहे हैं :)
UltimateByte

सिर्फ एक स्क्रिप्ट के लिए नहीं, बल्कि सिर्फ एक बैश स्क्रिप्ट के लिए।
Oskar Skog
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.