ShellCheck से स्थैतिक विश्लेषण और ऑडिट
ShellCheck को सुरक्षा जाँच-द्वार में जोड़ें और हर स्क्रिप्ट को अधिक सुरक्षित बनाने के लिए उसके निष्कर्षों की व्याख्या करें।
ShellCheck से स्थैतिक विश्लेषण और ऑडिट, CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
ShellCheck क्या है और यह क्यों महत्वपूर्ण है
ShellCheck शेल स्क्रिप्ट के लिए एक मुक्त-स्रोत स्थैतिक विश्लेषण उपकरण है। यह आपकी Bash (और POSIX sh, dash, ksh) स्रोत सामग्री को चलाए बिना उसका विश्लेषण करता है और बग, असुरक्षित संरचनाएँ, पोर्टेबिलिटी संबंधी समस्याएँ तथा शैली संबंधी समस्याएँ बताता है — हर समस्या को SC2086 जैसे अद्वितीय नियम कोड से चिह्नित किया जाता है।
सुरक्षा-सुदृढ़ पाइपलाइन में ShellCheck एक अनिवार्य द्वार की तरह काम करता है: पास होने तक कोई स्क्रिप्ट जारी नहीं की जाती। यह इसलिए महत्वपूर्ण है क्योंकि:
- कई शेल कमज़ोरियाँ (शब्द-विभाजन, इंजेक्शन, बिना उद्धरण वाला विस्तार) सामान्य परीक्षण के दौरान दिखाई नहीं देतीं, लेकिन हमलावर-नियंत्रित इनपुट पर सक्रिय हो जाती हैं।
- ShellCheck इन बग-श्रेणियों को रनटाइम से पहले, बिना किसी अतिरिक्त लागत के पकड़ लेता है।
- यह बताता है कि हर पैटर्न क्यों खतरनाक है, जिससे आपकी टीम समय के साथ अधिक सजग बनती है।
इसे किसी भी सिस्टम पर स्थापित करें:
# Debian / Ubuntu
sudo apt-get install shellcheck
# macOS (Homebrew)
brew install shellcheck
# From source via Cabal (any platform)
cabal update && cabal install ShellCheck
# Verify
shellcheck --versionपहली बार ShellCheck चलाना
सबसे सरल आह्वान shellcheck <script> है। ShellCheck शेल की बोली निर्धारित करने के लिए shebang पंक्ति पढ़ता है और फिर निष्कर्ष stdout पर भेजता है।
हर निष्कर्ष में शामिल होता है:
- फ़ाइल और पंक्ति संख्या — सटीक स्थान
- गंभीरता —
error,warning,infoयाstyle - SC कोड — स्थिर नियम पहचानकर्ता, जिसे खोजा या दबाया जा सकता है
- मानवीय व्याख्या — यह बताती है कि क्या गलत है और अक्सर इसे कैसे ठीक करना है
नीचे दी गई स्क्रिप्ट चलाएँ और देखें कि ShellCheck कैसा आउटपुट उत्पन्न करेगा:
#!/usr/bin/env bash
# demo_bad.sh — intentionally flawed for ShellCheck demonstration
FILE=$1
if [ $FILE == '' ]; then
echo "No file given"
fi
cat $FILE | grep 'error' | wc -lShellCheck आउटपुट और SC कोड की व्याख्या
पिछले दृश्य की स्क्रिप्ट के लिए ShellCheck इस तरह के निष्कर्ष देगा:
SC2086(चेतावनी) — ग्लोबिंग और शब्द-विभाजन रोकने के लिए दोहरे उद्धरण लगाएँ —[ $FILE == '' ]में$FILEऔरcat $FILEमें।SC2039/SC3010(जानकारी) — [ ] में == Bash की विशेषता है; POSIX के लिए = का उपयोग करें।SC2002(शैली) — अनावश्यक cat। cat file | cmd के बजाय cmd < file का उपयोग करने पर विचार करें।
हर SC कोड https://www.shellcheck.net/wiki/SCxxxx पर एक विकी पृष्ठ से जुड़ा है, जहाँ कारण और सुधारा हुआ उदाहरण दिया गया है।
उस स्क्रिप्ट का सुधरा हुआ संस्करण:
#!/usr/bin/env bash
# demo_fixed.sh — ShellCheck-clean
FILE="$1"
if [ -z "$FILE" ]; then
echo "No file given" >&2
exit 1
fi
grep -c 'error' "$FILE"गंभीरता के स्तर और किन पर कार्रवाई करनी है
ShellCheck हर निष्कर्ष को उसकी गंभीरता के आधार पर वर्गीकृत करता है। सुरक्षा-द्वार में इनके साथ इस प्रकार व्यवहार करें:
- error — लगभग निश्चित रूप से बग या सुरक्षा छेद। बिल्ड रोकें। तुरंत सुधारें। उदाहरण: shebang न होने पर
SC2148, बिना उद्धरण वाला$?होने परSC2070। - warning — उच्च-जोखिम वाला पैटर्न, जिसका अक्सर दुरुपयोग किया जा सकता है। बिल्ड रोकें। सुधारें या दबाने का स्पष्ट औचित्य दें। उदाहरण: बिना उद्धरण वाला चर होने पर
SC2086। - info — आज सही होने की संभावना है, लेकिन नाज़ुक या गैर-पोर्टेबल है। इसी PR में सुधारें, जब तक इसे दायरे से बाहर न ठहराया गया हो।
- style — दिखावटी या POSIX प्राथमिकता। शुद्ध Bash कोडबेस में अनुशंसित, लेकिन वैकल्पिक।
--severity=warning का उपयोग करें, ताकि केवल चेतावनी और उससे ऊपर की गंभीरता पर गैर-शून्य निकास मिले — यह मानक सुरक्षा-द्वार सीमा है:
#!/usr/bin/env bash
# gate.sh — fail CI on errors and warnings only
shellcheck --severity=warning scripts/*.sh
echo "ShellCheck exit code: $?"CI सुरक्षा-द्वार के रूप में ShellCheck का एकीकरण
सुरक्षा-द्वार तभी उपयोगी होता है, जब वह अनिवार्य और स्वचालित हो। नीचे दिया गया पैटर्न ShellCheck को ऐसे CI चरण में लपेटता है, जो:
- रिपॉज़िटरी में प्रत्येक
.shफ़ाइल खोजता है। - ShellCheck को
--severity=warningऔर मशीन-पठनीय JSON आउटपुट के साथ चलाता है। - यदि कोई निष्कर्ष मिले तो पाइपलाइन विफल कर देता है (
exit 1)। - सारांश छापता है, ताकि इंजीनियर CI लॉग छोड़े बिना निष्कर्षों पर कार्रवाई कर सकें।
इस फ़ाइल को अपने रिपॉज़िटरी में रखें और अपनी CI पाइपलाइन (GitHub Actions, Jenkins, GitLab CI आदि) से चलाएँ:
#!/usr/bin/env bash
# ci/shellcheck_gate.sh
set -euo pipefail
SCRIPTS=$(find . -name '*.sh' -not -path './.git/*')
FAILED=0
for script in $SCRIPTS; do
echo "==> Checking: $script"
if ! shellcheck --severity=warning --format=tty "$script"; then
FAILED=1
fi
done
if [ "$FAILED" -eq 1 ]; then
echo "[GATE] ShellCheck found warnings or errors. Build blocked." >&2
exit 1
fi
echo "[GATE] All scripts passed ShellCheck."SC2086 परिवार: बिना उद्धरण वाले चर विस्तार
SC2086 ShellCheck का सबसे आम निष्कर्ष और शेल की सबसे अधिक दुरुपयोग की जाने वाली कमज़ोरियों में से एक है: बिना उद्धरण वाले चर विस्तार।
जब किसी चर को दोहरे उद्धरण में नहीं रखा जाता, तो शेल उसके मान पर शब्द-विभाजन (IFS के आधार पर) और ग्लोब विस्तार करता है। जो हमलावर चर को नियंत्रित करता हो, वह अतिरिक्त तर्क डाल सकता है, फ़ाइल सिस्टम में अनधिकृत पथ-भ्रमण करा सकता है या कमांड को अप्रत्याशित ऑपरेंड दे सकता है।
पारंपरिक खतरनाक पैटर्न:
#!/usr/bin/env bash
# Attacker sets: FILENAME="important.txt /etc/passwd"
FILENAME="$1"
# UNSAFE — word splitting turns this into two args
rm $FILENAME
# SAFE — double quotes prevent splitting
rm "$FILENAME"
# Arrays are the right tool for lists
FILES=("$@")
rm -- "${FILES[@]}"SC2046 और SC2035 से कमांड इंजेक्शन के जोखिम का पता लगाना
दो कम-ज्ञात लेकिन महत्वपूर्ण नियम सबशेल आउटपुट के माध्यम से कमांड इंजेक्शन से संबंधित हैं:
SC2046—$(…)के भीतर शब्द-विभाजन / ग्लोब रोकने के लिए इसे उद्धरण में रखें। यदि सबशेल का आउटपुट बिना उद्धरण के उपयोग किया जाता है, तो उसमें मौजूद कोई भी रिक्त स्थान या ग्लोब वर्ण शेल टोकन बन जाता है।SC2035—-से शुरू होने वाली फ़ाइलों को विकल्प समझे जाने से बचाने के लिए*.shके बजाय./*.shका उपयोग करें (यह तर्क इंजेक्शन का पारंपरिक माध्यम है)।
ठोस शोषण परिदृश्य और समाधान:
#!/usr/bin/env bash
# SC2046 example — output of find fed unquoted to chmod
# If a filename contains spaces, extra arguments appear
# UNSAFE
chmod 600 $(find /secrets -name '*.key')
# SAFE — use a while-read loop or xargs with -0
find /secrets -name '*.key' -print0 \
| xargs -0 chmod 600
# SC2035 example
# UNSAFE — a file named '-rf' would be passed as an option
rm *.sh
# SAFE
rm -- ./*.shस्वचालन के लिए JSON आउटपुट प्रारूप का उपयोग
ShellCheck --format के माध्यम से कई आउटपुट प्रारूपों का समर्थन करता है:
tty(डिफ़ॉल्ट) — मनुष्यों के पढ़ने योग्य टर्मिनल आउटपुटjson— मशीन-पठनीय; डैशबोर्ड, कस्टम अवरोधक या SAST प्लेटफ़ॉर्म पर अपलोड करने के लिए आदर्शgcc— GCC त्रुटि प्रारूप को पढ़ने वाले उपकरणों (IDE, Vim/Emacs) के साथ संगतcheckstyle— Jenkins Checkstyle प्लगइन द्वारा उपयोग किया जाने वाला XML प्रारूप
JSON प्रारूप से आप स्वचालित नीतियाँ लिख सकते हैं, जैसे केवल विशिष्ट SC कोड पर रोक लगाना या बड़े कोडबेस के निष्कर्षों को एक सुरक्षा रिपोर्ट में एकत्र करना।
#!/usr/bin/env bash
# Emit JSON and filter for only error-severity findings using jq
shellcheck --format=json scripts/deploy.sh \
| jq '[.[] | select(.level == "error")]'
# Count distinct SC codes across all scripts
find . -name '*.sh' -print0 \
| xargs -0 shellcheck --format=json 2>/dev/null \
| jq '[.[] | .code] | group_by(.) | map({code: .[0], count: length}) | sort_by(-.count)'गलत सकारात्मक निष्कर्षों को सही ढंग से दबाना
ShellCheck को बिना भेदभाव के अक्षम करना उसके उद्देश्य को विफल कर देता है। सही तरीका लक्षित और दस्तावेज़ित दमन है, जो केवल उस सटीक पंक्ति या खंड को प्रभावित करे जहाँ निष्कर्ष वास्तव में लागू नहीं होता।
दमन के तीन तरीके:
- इनलाइन अक्षम करना — समस्या वाले कोड के ठीक ऊपर वाली पंक्ति पर
# shellcheck disable=SC2086। इसका प्रभाव केवल उस पंक्ति पर पड़ता है। - खंड को अक्षम/सक्षम करना — किसी खंड को
# shellcheck disable=…और# shellcheck enable=…के बीच रखें। - फ़ाइल-स्तरीय निर्देश — फ़ाइल के शीर्ष पर
# shellcheck disable=…रखें (इसका औचित्य बहुत कम मामलों में होता है; कारण लिखें)।
हर दमन में अनिवार्य रूप से ऐसी टिप्पणी होनी चाहिए जो बताए कि निष्कर्ष गलत सकारात्मक क्यों है:
#!/usr/bin/env bash
# deploy.sh
# Legitimate suppression: $DEPLOY_ARGS is intentionally word-split
# because it is a pre-validated list of flags from a trusted config file.
# shellcheck disable=SC2086
exec deploy-tool $DEPLOY_ARGS
# Block suppression for a section that generates dynamic code
# shellcheck disable=SC2016
VARS='$HOME $PATH $USER'
echo "Unexpanded vars: $VARS"
# shellcheck enable=SC2016.shellcheckrc के माध्यम से ShellCheck को कॉन्फ़िगर करना
पूरे प्रोजेक्ट की सेटिंग के लिए ShellCheck स्क्रिप्ट की निर्देशिका से ऊपर की ओर / तक .shellcheckrc पढ़ता है। इससे हर बार फ़्लैग दोहराने से बचते हैं और सुरक्षा-द्वार वाली स्क्रिप्ट सरल रहती हैं।
.shellcheckrc में उपयोगी निर्देश:
shell=bash— बोली का स्वतः पता लगाना अधिभावी करें (shebang रहित फ़ाइलों के लिए उपयोगी)enable=all— वैकल्पिक जाँच सक्रिय करें (जैसेavoid-nullary-conditions,require-variable-braces)disable=SC2059— उचित रूप से स्पष्ट किए गए अपवाद के लिए पूरे प्रोजेक्ट में दमनexternal-sources=true—source/.निर्देशों का अनुसरण और परीक्षण करें
# .shellcheckrc — project root
shell=bash
enable=all
external-sources=true
# SC2312: consider invoking this command separately to avoid masking its
# return value — suppressed project-wide because we use set -e.
# Rationale: errexit already aborts on failure; masking risk is mitigated.
disable=SC2312सिरे से सुदृढ़ स्क्रिप्ट: पहले और बाद में
ShellCheck के निष्कर्षों को आत्मसात करने का सबसे प्रभावी तरीका किसी वास्तविक स्क्रिप्ट को विफल अवस्था से साफ़-सुथरी, सुदृढ़ अवस्था में पुनर्गठित करना है। नीचे दी गई स्क्रिप्ट एक निर्देशिका का बैकअप लेती है और सुरक्षा को ध्यान में रखे बिना लिखी गई थी। यह कम-से-कम पाँच अलग-अलग नियमों पर ShellCheck में विफल होती है।
दोनों संस्करणों का अध्ययन करें। बाद वाला संस्करण बिना किसी दमन निर्देश के shellcheck --severity=warning सफलतापूर्वक पार करता है और हमलावर-नियंत्रित इनपुट के सामने काफ़ी अधिक सुरक्षित है:
#!/usr/bin/env bash
# BEFORE — multiple ShellCheck violations
DEST=$1
SRC=$2
DATE=`date +%Y%m%d`
if [ ! -d $DEST ]; then
mkdir $DEST
fi
cp -r $SRC $DEST/$DATE
echo Done
#!/usr/bin/env bash
# AFTER — ShellCheck-clean and hardened
set -euo pipefail
DEST="${1:?Usage: backup.sh <dest> <src>}"
SRC="${2:?Usage: backup.sh <dest> <src>}"
DATE=$(date +%Y%m%d)
if [ ! -d "$DEST" ]; then
mkdir -p -- "$DEST"
fi
cp -r -- "$SRC" "$DEST/$DATE"
echo 'Done' >&2ज्ञान जाँच: सुरक्षा-द्वार में ShellCheck
सुरक्षा-द्वार की भूमिका के रूप में ShellCheck की अपनी समझ का परीक्षण करें।
पुनरावलोकन: सुरक्षा-द्वार के रूप में स्थैतिक विश्लेषण
इस पाठ में आपने सीखा कि अपने Bash कार्यप्रवाह में ShellCheck को अनिवार्य सुरक्षा-द्वार कैसे बनाया जाए:
- ShellCheck आपकी स्क्रिप्ट चलाए बिना स्थैतिक विश्लेषण करता है और रनटाइम से पहले उद्धरण संबंधी त्रुटियाँ, इंजेक्शन के जोखिम तथा असुरक्षित पैटर्न पकड़ लेता है।
- हर निष्कर्ष में एक SC कोड (जैसे
SC2086) होता है, जो विस्तृत दस्तावेज़ और सुधार संबंधी मार्गदर्शन से जुड़ा होता है। - गंभीरता-क्रम —
error,warning,info,style— आपको सुरक्षा-द्वार की सीमा तय करने देता है:--severity=warningअनुशंसित सुरक्षा सीमा है। - रिपोर्टिंग, रुझान-आकलन और SAST एकीकरण को स्वचालित करने के लिए मशीन-पठनीय आउटपुट (
--format=json) का उपयोग करें। - दमन का संयम से उपयोग करें: हमेशा एकल पंक्ति को लक्षित करें, टिप्पणी में कारण अवश्य लिखें और औचित्य के बिना कभी भी पूरे स्तर पर दमन न करें; औचित्य होने पर
.shellcheckrcका उपयोग करें। - गहन सुरक्षा के लिए ShellCheck को
set -euo pipefail, स्पष्ट उद्धरण,-- argumentसमापक और इनपुट सत्यापन के साथ उपयोग करें।
ShellCheck में सफल होने वाली स्क्रिप्ट अपने-आप सुरक्षित नहीं हो जाती — लेकिन ShellCheck में विफल होने वाली स्क्रिप्ट को कभी भी उत्पादन तक नहीं पहुँचना चाहिए।
एआई शिक्षक के साथ Bash सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 22
- पाठ
- 88
अक्सर पूछे जाने वाले प्रश्न
क्या “ShellCheck से स्थैतिक विश्लेषण और ऑडिट” पाठ निःशुल्क है?
हाँ—“ShellCheck से स्थैतिक विश्लेषण और ऑडिट” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“ShellCheck से स्थैतिक विश्लेषण और ऑडिट” में मैं क्या सीखूँगा?
ShellCheck को सुरक्षा जाँच-द्वार में जोड़ें और हर स्क्रिप्ट को अधिक सुरक्षित बनाने के लिए उसके निष्कर्षों की व्याख्या करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“ShellCheck से स्थैतिक विश्लेषण और ऑडिट” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- कमांड और तर्क इंजेक्शन रोकना
- गोपनीय जानकारी का सुरक्षित प्रबंधन और परिवेश की स्वच्छता
- न्यूनतम-अधिकार निष्पादन और sudo अनुशासन
- ShellCheck से स्थैतिक विश्लेषण और ऑडिट