How do I syntax check a Bash script without running it?
225
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
linux bash unix syntax gnu
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
add a comment |
225
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
linux bash unix syntax gnu
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47
add a comment |
225
225
225
73
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
linux bash unix syntax gnu
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
linux bash unix syntax gnu
linux bash unix syntax gnu
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
edited Mar 5 '18 at 21:29
codeforester
17.4k83864
17.4k83864
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
asked Oct 5 '08 at 12:51
Tom FeinerTom Feiner
8,181164251
8,181164251
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47
add a comment |
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47
add a comment |
7 Answers
7
active
oldest
votes
327
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options thatsetdoes.
– ephemient
Oct 5 '08 at 20:55
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing spaceif ["$var" == "string" ]instead ofif [ "$var" == "string" ]
– Brynjar
Aug 5 '11 at 16:13
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.type [says "[ is a shell builtin". It ultimately delegates to thetestprogram, but it expects a closing bracket, as well. So it's likeif test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.
– Joshua Cheek
Jul 20 '14 at 4:30
2
@JoshuaCheek: Builtin[is only invoked in this case if$varhappens to expand to an empty string. If$varexpands to a non-empty string,[is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use[[instead of[, even though[[is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.
– mklement0
Jun 11 '15 at 21:55
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:["$var"is syntactically a valid command-name expression; similarly, tokens==and"$string"are valid command arguments. (Generally, builtin[is parsed with command syntax, whereas[[- as a shell keyword - is parsed differently.) The shell builtin[does not delegate to the "testprogram" (external utility):bash,dash,ksh,zshall have builtin versions of both[andtest, and they do not call their external-utility counterparts.
– mklement0
Jun 11 '15 at 23:02
|
show 5 more comments
100
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
3
Great tip; on OSX you can now also install the shellcheck.net CLI,shellcheck, via Homebrew:brew install shellcheck.
– mklement0
Jun 12 '15 at 2:20
2
Also on debian&friends:apt-get install shellcheck
– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed fromtrusty-backports.
– Peterino
Aug 4 '15 at 21:19
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
|
show 1 more comment
37
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 forset -ualthough this does not really answer the question, because you have to run the script to get the error message. Not evenbash -n check_init.shshows that warning
– rubo77
Jul 6 '17 at 9:30
add a comment |
22
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
add a comment |
3
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17 '14 at 10:41
mug896mug896
8741012
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, becauseset -xshows every line before it is executed
– rubo77
Jul 6 '17 at 9:32
add a comment |
3
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -exec bash -n {} ;
If you want to use it for a single file, just edit the wildcard with the name of the file.
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
add a comment |
1
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
But it won't work if your files don't end with.shor other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with.erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!
– Greg Dubicki
Sep 22 '16 at 8:40
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f171924%2fhow-do-i-syntax-check-a-bash-script-without-running-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
327
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options thatsetdoes.
– ephemient
Oct 5 '08 at 20:55
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing spaceif ["$var" == "string" ]instead ofif [ "$var" == "string" ]
– Brynjar
Aug 5 '11 at 16:13
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.type [says "[ is a shell builtin". It ultimately delegates to thetestprogram, but it expects a closing bracket, as well. So it's likeif test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.
– Joshua Cheek
Jul 20 '14 at 4:30
2
@JoshuaCheek: Builtin[is only invoked in this case if$varhappens to expand to an empty string. If$varexpands to a non-empty string,[is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use[[instead of[, even though[[is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.
– mklement0
Jun 11 '15 at 21:55
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:["$var"is syntactically a valid command-name expression; similarly, tokens==and"$string"are valid command arguments. (Generally, builtin[is parsed with command syntax, whereas[[- as a shell keyword - is parsed differently.) The shell builtin[does not delegate to the "testprogram" (external utility):bash,dash,ksh,zshall have builtin versions of both[andtest, and they do not call their external-utility counterparts.
– mklement0
Jun 11 '15 at 23:02
|
show 5 more comments
327
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options thatsetdoes.
– ephemient
Oct 5 '08 at 20:55
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing spaceif ["$var" == "string" ]instead ofif [ "$var" == "string" ]
– Brynjar
Aug 5 '11 at 16:13
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.type [says "[ is a shell builtin". It ultimately delegates to thetestprogram, but it expects a closing bracket, as well. So it's likeif test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.
– Joshua Cheek
Jul 20 '14 at 4:30
2
@JoshuaCheek: Builtin[is only invoked in this case if$varhappens to expand to an empty string. If$varexpands to a non-empty string,[is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use[[instead of[, even though[[is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.
– mklement0
Jun 11 '15 at 21:55
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:["$var"is syntactically a valid command-name expression; similarly, tokens==and"$string"are valid command arguments. (Generally, builtin[is parsed with command syntax, whereas[[- as a shell keyword - is parsed differently.) The shell builtin[does not delegate to the "testprogram" (external utility):bash,dash,ksh,zshall have builtin versions of both[andtest, and they do not call their external-utility counterparts.
– mklement0
Jun 11 '15 at 23:02
|
show 5 more comments
327
327
327
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
edited Nov 15 '12 at 15:47
Chris
28.9k1096127
28.9k1096127
answered Oct 5 '08 at 12:55
andyandy
5,42311417
answered Oct 5 '08 at 12:55
andyandy
5,42311417
answered Oct 5 '08 at 12:55
andyandy
5,42311417
5,42311417
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options thatsetdoes.
– ephemient
Oct 5 '08 at 20:55
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing spaceif ["$var" == "string" ]instead ofif [ "$var" == "string" ]
– Brynjar
Aug 5 '11 at 16:13
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.type [says "[ is a shell builtin". It ultimately delegates to thetestprogram, but it expects a closing bracket, as well. So it's likeif test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.
– Joshua Cheek
Jul 20 '14 at 4:30
2
@JoshuaCheek: Builtin[is only invoked in this case if$varhappens to expand to an empty string. If$varexpands to a non-empty string,[is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use[[instead of[, even though[[is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.
– mklement0
Jun 11 '15 at 21:55
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:["$var"is syntactically a valid command-name expression; similarly, tokens==and"$string"are valid command arguments. (Generally, builtin[is parsed with command syntax, whereas[[- as a shell keyword - is parsed differently.) The shell builtin[does not delegate to the "testprogram" (external utility):bash,dash,ksh,zshall have builtin versions of both[andtest, and they do not call their external-utility counterparts.
– mklement0
Jun 11 '15 at 23:02
|
show 5 more comments
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options thatsetdoes.
– ephemient
Oct 5 '08 at 20:55
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing spaceif ["$var" == "string" ]instead ofif [ "$var" == "string" ]
– Brynjar
Aug 5 '11 at 16:13
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.type [says "[ is a shell builtin". It ultimately delegates to thetestprogram, but it expects a closing bracket, as well. So it's likeif test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.
– Joshua Cheek
Jul 20 '14 at 4:30
2
@JoshuaCheek: Builtin[is only invoked in this case if$varhappens to expand to an empty string. If$varexpands to a non-empty string,[is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use[[instead of[, even though[[is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.
– mklement0
Jun 11 '15 at 21:55
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:["$var"is syntactically a valid command-name expression; similarly, tokens==and"$string"are valid command arguments. (Generally, builtin[is parsed with command syntax, whereas[[- as a shell keyword - is parsed differently.) The shell builtin[does not delegate to the "testprogram" (external utility):bash,dash,ksh,zshall have builtin versions of both[andtest, and they do not call their external-utility counterparts.
– mklement0
Jun 11 '15 at 23:02
8
8
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options that
set does.– ephemient
Oct 5 '08 at 20:55
In bash's manpage, under "SHELL BUILTIN COMMANDS / set", -n is documented, and as the beginning of the manpage states, bash interprets all single-character options that
set does.– ephemient
Oct 5 '08 at 20:55
20
20
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing space
if ["$var" == "string" ] instead of if [ "$var" == "string" ]– Brynjar
Aug 5 '11 at 16:13
to add to the (for me) non obvious caveat, it also won't catch an error caused by a missing space
if ["$var" == "string" ] instead of if [ "$var" == "string" ]– Brynjar
Aug 5 '11 at 16:13
11
11
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.
type [ says "[ is a shell builtin". It ultimately delegates to the test program, but it expects a closing bracket, as well. So it's like if test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.– Joshua Cheek
Jul 20 '14 at 4:30
@Brynjar That's because it's just syntax checking. The open bracket isn't syntax, that's the name of the function to run.
type [ says "[ is a shell builtin". It ultimately delegates to the test program, but it expects a closing bracket, as well. So it's like if test"$var", which isn't what the author meant, but is syntactically valid (say $var has a value of "a", then we will see "bash: testa: command not found"). Point is that syntactically, there is no missing space.– Joshua Cheek
Jul 20 '14 at 4:30
2
2
@JoshuaCheek: Builtin
[ is only invoked in this case if $var happens to expand to an empty string. If $var expands to a non-empty string, [ is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use [[ instead of [, even though [[ is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.– mklement0
Jun 11 '15 at 21:55
@JoshuaCheek: Builtin
[ is only invoked in this case if $var happens to expand to an empty string. If $var expands to a non-empty string, [ is concatenated with that string and is interpreted as a command name (not function name) by Bash, and, yes, that is syntactically valid, but, as you state, obviously not the intent. If you use [[ instead of [, even though [[ is a shell keyword (rather than a builtin), you'll get the same result, because the unintended string concatenation still overrides recognition of the keyword.– mklement0
Jun 11 '15 at 21:55
2
2
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:
["$var" is syntactically a valid command-name expression; similarly, tokens == and "$string" are valid command arguments. (Generally, builtin [ is parsed with command syntax, whereas [[ - as a shell keyword - is parsed differently.) The shell builtin [ does not delegate to the "test program" (external utility): bash, dash, ksh, zsh all have builtin versions of both [ and test, and they do not call their external-utility counterparts.– mklement0
Jun 11 '15 at 23:02
@JoshuaCheek: Bash is still syntax-checking here: it's checking simple-command invocation syntax:
["$var" is syntactically a valid command-name expression; similarly, tokens == and "$string" are valid command arguments. (Generally, builtin [ is parsed with command syntax, whereas [[ - as a shell keyword - is parsed differently.) The shell builtin [ does not delegate to the "test program" (external utility): bash, dash, ksh, zsh all have builtin versions of both [ and test, and they do not call their external-utility counterparts.– mklement0
Jun 11 '15 at 23:02
|
show 5 more comments
100
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
3
Great tip; on OSX you can now also install the shellcheck.net CLI,shellcheck, via Homebrew:brew install shellcheck.
– mklement0
Jun 12 '15 at 2:20
2
Also on debian&friends:apt-get install shellcheck
– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed fromtrusty-backports.
– Peterino
Aug 4 '15 at 21:19
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
|
show 1 more comment
100
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
3
Great tip; on OSX you can now also install the shellcheck.net CLI,shellcheck, via Homebrew:brew install shellcheck.
– mklement0
Jun 12 '15 at 2:20
2
Also on debian&friends:apt-get install shellcheck
– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed fromtrusty-backports.
– Peterino
Aug 4 '15 at 21:19
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
|
show 1 more comment
100
100
100
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
edited Jan 3 '16 at 0:52
user2350426
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
answered Oct 24 '13 at 17:55
dvd818dvd818
1,132179
1,132179
3
Great tip; on OSX you can now also install the shellcheck.net CLI,shellcheck, via Homebrew:brew install shellcheck.
– mklement0
Jun 12 '15 at 2:20
2
Also on debian&friends:apt-get install shellcheck
– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed fromtrusty-backports.
– Peterino
Aug 4 '15 at 21:19
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
|
show 1 more comment
3
Great tip; on OSX you can now also install the shellcheck.net CLI,shellcheck, via Homebrew:brew install shellcheck.
– mklement0
Jun 12 '15 at 2:20
2
Also on debian&friends:apt-get install shellcheck
– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed fromtrusty-backports.
– Peterino
Aug 4 '15 at 21:19
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
3
3
Great tip; on OSX you can now also install the shellcheck.net CLI,
shellcheck, via Homebrew: brew install shellcheck.– mklement0
Jun 12 '15 at 2:20
Great tip; on OSX you can now also install the shellcheck.net CLI,
shellcheck, via Homebrew: brew install shellcheck.– mklement0
Jun 12 '15 at 2:20
2
2
Also on debian&friends:
apt-get install shellcheck– that other guy
Jul 31 '15 at 1:36
Also on debian&friends:
apt-get install shellcheck– that other guy
Jul 31 '15 at 1:36
For Ubuntu trusty this package must be installed from
trusty-backports.– Peterino
Aug 4 '15 at 21:19
For Ubuntu trusty this package must be installed from
trusty-backports.– Peterino
Aug 4 '15 at 21:19
1
1
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
This should be the accepted answer!
– Greg Dubicki
Sep 22 '16 at 8:36
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
As mentioned above, trusty dependency needed, and can install it as below in ubuntu 14.04: sudo apt-get -f install, then: sudo sudo apt-get install shellcheck
– zhihong
Dec 8 '16 at 15:32
|
show 1 more comment
37
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 forset -ualthough this does not really answer the question, because you have to run the script to get the error message. Not evenbash -n check_init.shshows that warning
– rubo77
Jul 6 '17 at 9:30
add a comment |
37
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 forset -ualthough this does not really answer the question, because you have to run the script to get the error message. Not evenbash -n check_init.shshows that warning
– rubo77
Jul 6 '17 at 9:30
add a comment |
37
37
37
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
edited Sep 30 '12 at 6:57
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
answered May 23 '12 at 14:10
Diego TerceroDiego Tercero
84311016
84311016
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 forset -ualthough this does not really answer the question, because you have to run the script to get the error message. Not evenbash -n check_init.shshows that warning
– rubo77
Jul 6 '17 at 9:30
add a comment |
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 forset -ualthough this does not really answer the question, because you have to run the script to get the error message. Not evenbash -n check_init.shshows that warning
– rubo77
Jul 6 '17 at 9:30
4
4
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
i set these flags always in my bash scripts, if it passes these, it's good to go "set -o errexit" "set -o nounset" "set -o pipefail"
– μολὼν.λαβέ
Jan 10 '16 at 6:30
+1 for
set -u although this does not really answer the question, because you have to run the script to get the error message. Not even bash -n check_init.sh shows that warning– rubo77
Jul 6 '17 at 9:30
+1 for
set -u although this does not really answer the question, because you have to run the script to get the error message. Not even bash -n check_init.sh shows that warning– rubo77
Jul 6 '17 at 9:30
add a comment |
22
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
add a comment |
22
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
add a comment |
22
22
22
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
edited May 3 '12 at 16:56
Rob Hruska
91.9k25149179
91.9k25149179
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
answered Feb 2 '11 at 13:16
JeevanJeevan
22122
22122
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
add a comment |
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
3
3
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
+1 for the return value check.
– GuruM
Sep 5 '11 at 12:47
1
1
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Though not exactly related to bash syntax check - using set -x and set +x for debugging the full script or sections of the script is quite useful
– GuruM
Aug 1 '12 at 12:47
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
Thanks for this didn't know didn't know about the -n but what I wanted was @GuruM > sh -x test.sh as that displays the generated output of the script
– zzapper
Jun 19 '13 at 10:24
1
1
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
Yes. I forgot to mention that you can do the following At command line: 1) bash -x test.sh #this runs the whole script in 'debug mode' 2) set +x; bash test.sh; set -x #set debug mode on/off before/after script run In the script: a) #!/bin/bash -x #add 'debug mode' at top of script b) set +x; code; set -x #add 'debug mode' for any section of script
– GuruM
Jun 19 '13 at 13:23
add a comment |
3
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17 '14 at 10:41
mug896mug896
8741012
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, becauseset -xshows every line before it is executed
– rubo77
Jul 6 '17 at 9:32
add a comment |
3
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17 '14 at 10:41
mug896mug896
8741012
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, becauseset -xshows every line before it is executed
– rubo77
Jul 6 '17 at 9:32
add a comment |
3
3
3
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17 '14 at 10:41
mug896mug896
8741012
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17 '14 at 10:41
mug896mug896
8741012
edited Jan 17 '14 at 10:54
answered Jan 17 '14 at 10:41
mug896mug896
8741012
answered Jan 17 '14 at 10:41
mug896mug896
8741012
answered Jan 17 '14 at 10:41
mug896mug896
8741012
8741012
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, becauseset -xshows every line before it is executed
– rubo77
Jul 6 '17 at 9:32
add a comment |
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, becauseset -xshows every line before it is executed
– rubo77
Jul 6 '17 at 9:32
How does this work?
– unfa
May 8 '17 at 11:46
How does this work?
– unfa
May 8 '17 at 11:46
it use parameter expansions
– mug896
May 8 '17 at 16:44
it use parameter expansions
– mug896
May 8 '17 at 16:44
this works, because
set -x shows every line before it is executed– rubo77
Jul 6 '17 at 9:32
this works, because
set -x shows every line before it is executed– rubo77
Jul 6 '17 at 9:32
add a comment |
3
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -exec bash -n {} ;
If you want to use it for a single file, just edit the wildcard with the name of the file.
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
add a comment |
3
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -exec bash -n {} ;
If you want to use it for a single file, just edit the wildcard with the name of the file.
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
add a comment |
3
3
3
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -exec bash -n {} ;
If you want to use it for a single file, just edit the wildcard with the name of the file.
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -exec bash -n {} ;
If you want to use it for a single file, just edit the wildcard with the name of the file.
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
answered Aug 3 '17 at 11:58
Gerald HughesGerald Hughes
1,88253576
1,88253576
add a comment |
add a comment |
1
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
But it won't work if your files don't end with.shor other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with.erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!
– Greg Dubicki
Sep 22 '16 at 8:40
add a comment |
1
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
But it won't work if your files don't end with.shor other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with.erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!
– Greg Dubicki
Sep 22 '16 at 8:40
add a comment |
1
1
1
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
answered Dec 5 '15 at 18:17
CengizCengiz
3,05463667
3,05463667
But it won't work if your files don't end with.shor other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with.erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!
– Greg Dubicki
Sep 22 '16 at 8:40
add a comment |
But it won't work if your files don't end with.shor other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with.erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!
– Greg Dubicki
Sep 22 '16 at 8:40
But it won't work if your files don't end with
.sh or other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with .erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!– Greg Dubicki
Sep 22 '16 at 8:40
But it won't work if your files don't end with
.sh or other extension associated with Bash scripts, which is the case if you generate the scripts using some templating tool like ERB (then they end with .erb). Please vote for youtrack.jetbrains.com/issue/IDEA-79574 if you want it fixed!– Greg Dubicki
Sep 22 '16 at 8:40
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f171924%2fhow-do-i-syntax-check-a-bash-script-without-running-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Related: Is there a static analysis tool like Lint or Perl::Critic for shell scripts?
– blong
Jun 3 '14 at 20:47