shell script giving error
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I have a small shell script which is throwing error:
unexpected end of file
The script follows:
#!
if [ t -eq 1 ]
then
echo " TEST1 "
else
echo " TEST LAST LOOP "
fi
shell-script
add a comment |Â
up vote
0
down vote
favorite
I have a small shell script which is throwing error:
unexpected end of file
The script follows:
#!
if [ t -eq 1 ]
then
echo " TEST1 "
else
echo " TEST LAST LOOP "
fi
shell-script
What's the output ofsed -n l < your-script
?
â Stéphane Chazelas
Mar 23 at 17:11
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a small shell script which is throwing error:
unexpected end of file
The script follows:
#!
if [ t -eq 1 ]
then
echo " TEST1 "
else
echo " TEST LAST LOOP "
fi
shell-script
I have a small shell script which is throwing error:
unexpected end of file
The script follows:
#!
if [ t -eq 1 ]
then
echo " TEST1 "
else
echo " TEST LAST LOOP "
fi
shell-script
edited Mar 23 at 16:40
Vlastimil
6,3661146117
6,3661146117
asked Mar 23 at 7:26
Priya
6
6
What's the output ofsed -n l < your-script
?
â Stéphane Chazelas
Mar 23 at 17:11
add a comment |Â
What's the output ofsed -n l < your-script
?
â Stéphane Chazelas
Mar 23 at 17:11
What's the output of
sed -n l < your-script
?â Stéphane Chazelas
Mar 23 at 17:11
What's the output of
sed -n l < your-script
?â Stéphane Chazelas
Mar 23 at 17:11
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
5
down vote
There is nothing in the script that should give that error. If you run the script with sh ./script.sh
, it will produce
TEST LAST LOOP
as output. If running it with bash ./script.sh
you will get the same output, but with an additional "integer expression expected" error since t
is not an integer (this may also happen if you run with sh
if your sh
is implemented by bash
). If you run it with ./script.sh
, the shell will most likely complain with "No such file or directory" since you have not added a proper #!
-line.
In this script, you may use #!/bin/sh
as the #!
-line as you only use standard POSIX features.
The test [ t -eq 1 ]
will never be true as t
(the character) is not an integer. If you're setting the variable t
to an integer somewhere, use [ "$t" -eq 1 ]
in the test.
The only way I can get a shell to say "unexpected end of file" is by converting the script to a DOS text file and running it with bash
.
If you get this error, then the script file is probably a DOS text file (possibly due to being created on a Windows machine). You should run dos2unix
on the script.
See questions related to dos2unix
.
3
[ t -eq 1]
may be true with somesh
implementations if at
environment variable has been defined with a value that is an arithmetic expression that resolves to1
. For instance,t=20/20 ksh93 -c '[ t -eq 1 ]'
is true.t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.
â Stéphane Chazelas
Mar 23 at 17:06
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with thatksh93
thing, but the wording of the error message won't be exactly the same though.
â Kusalananda
Mar 23 at 17:15
add a comment |Â
up vote
0
down vote
Missing the shebang line #!/bin/sh
and t
isn't defined
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
add a comment |Â
up vote
0
down vote
- replace
#!
by#!/bin/sh
or runsh ./script.sh
, and you must set t as integer$t
nott
.
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
There is nothing in the script that should give that error. If you run the script with sh ./script.sh
, it will produce
TEST LAST LOOP
as output. If running it with bash ./script.sh
you will get the same output, but with an additional "integer expression expected" error since t
is not an integer (this may also happen if you run with sh
if your sh
is implemented by bash
). If you run it with ./script.sh
, the shell will most likely complain with "No such file or directory" since you have not added a proper #!
-line.
In this script, you may use #!/bin/sh
as the #!
-line as you only use standard POSIX features.
The test [ t -eq 1 ]
will never be true as t
(the character) is not an integer. If you're setting the variable t
to an integer somewhere, use [ "$t" -eq 1 ]
in the test.
The only way I can get a shell to say "unexpected end of file" is by converting the script to a DOS text file and running it with bash
.
If you get this error, then the script file is probably a DOS text file (possibly due to being created on a Windows machine). You should run dos2unix
on the script.
See questions related to dos2unix
.
3
[ t -eq 1]
may be true with somesh
implementations if at
environment variable has been defined with a value that is an arithmetic expression that resolves to1
. For instance,t=20/20 ksh93 -c '[ t -eq 1 ]'
is true.t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.
â Stéphane Chazelas
Mar 23 at 17:06
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with thatksh93
thing, but the wording of the error message won't be exactly the same though.
â Kusalananda
Mar 23 at 17:15
add a comment |Â
up vote
5
down vote
There is nothing in the script that should give that error. If you run the script with sh ./script.sh
, it will produce
TEST LAST LOOP
as output. If running it with bash ./script.sh
you will get the same output, but with an additional "integer expression expected" error since t
is not an integer (this may also happen if you run with sh
if your sh
is implemented by bash
). If you run it with ./script.sh
, the shell will most likely complain with "No such file or directory" since you have not added a proper #!
-line.
In this script, you may use #!/bin/sh
as the #!
-line as you only use standard POSIX features.
The test [ t -eq 1 ]
will never be true as t
(the character) is not an integer. If you're setting the variable t
to an integer somewhere, use [ "$t" -eq 1 ]
in the test.
The only way I can get a shell to say "unexpected end of file" is by converting the script to a DOS text file and running it with bash
.
If you get this error, then the script file is probably a DOS text file (possibly due to being created on a Windows machine). You should run dos2unix
on the script.
See questions related to dos2unix
.
3
[ t -eq 1]
may be true with somesh
implementations if at
environment variable has been defined with a value that is an arithmetic expression that resolves to1
. For instance,t=20/20 ksh93 -c '[ t -eq 1 ]'
is true.t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.
â Stéphane Chazelas
Mar 23 at 17:06
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with thatksh93
thing, but the wording of the error message won't be exactly the same though.
â Kusalananda
Mar 23 at 17:15
add a comment |Â
up vote
5
down vote
up vote
5
down vote
There is nothing in the script that should give that error. If you run the script with sh ./script.sh
, it will produce
TEST LAST LOOP
as output. If running it with bash ./script.sh
you will get the same output, but with an additional "integer expression expected" error since t
is not an integer (this may also happen if you run with sh
if your sh
is implemented by bash
). If you run it with ./script.sh
, the shell will most likely complain with "No such file or directory" since you have not added a proper #!
-line.
In this script, you may use #!/bin/sh
as the #!
-line as you only use standard POSIX features.
The test [ t -eq 1 ]
will never be true as t
(the character) is not an integer. If you're setting the variable t
to an integer somewhere, use [ "$t" -eq 1 ]
in the test.
The only way I can get a shell to say "unexpected end of file" is by converting the script to a DOS text file and running it with bash
.
If you get this error, then the script file is probably a DOS text file (possibly due to being created on a Windows machine). You should run dos2unix
on the script.
See questions related to dos2unix
.
There is nothing in the script that should give that error. If you run the script with sh ./script.sh
, it will produce
TEST LAST LOOP
as output. If running it with bash ./script.sh
you will get the same output, but with an additional "integer expression expected" error since t
is not an integer (this may also happen if you run with sh
if your sh
is implemented by bash
). If you run it with ./script.sh
, the shell will most likely complain with "No such file or directory" since you have not added a proper #!
-line.
In this script, you may use #!/bin/sh
as the #!
-line as you only use standard POSIX features.
The test [ t -eq 1 ]
will never be true as t
(the character) is not an integer. If you're setting the variable t
to an integer somewhere, use [ "$t" -eq 1 ]
in the test.
The only way I can get a shell to say "unexpected end of file" is by converting the script to a DOS text file and running it with bash
.
If you get this error, then the script file is probably a DOS text file (possibly due to being created on a Windows machine). You should run dos2unix
on the script.
See questions related to dos2unix
.
edited Mar 23 at 7:47
answered Mar 23 at 7:41
Kusalananda
102k13201317
102k13201317
3
[ t -eq 1]
may be true with somesh
implementations if at
environment variable has been defined with a value that is an arithmetic expression that resolves to1
. For instance,t=20/20 ksh93 -c '[ t -eq 1 ]'
is true.t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.
â Stéphane Chazelas
Mar 23 at 17:06
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with thatksh93
thing, but the wording of the error message won't be exactly the same though.
â Kusalananda
Mar 23 at 17:15
add a comment |Â
3
[ t -eq 1]
may be true with somesh
implementations if at
environment variable has been defined with a value that is an arithmetic expression that resolves to1
. For instance,t=20/20 ksh93 -c '[ t -eq 1 ]'
is true.t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.
â Stéphane Chazelas
Mar 23 at 17:06
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with thatksh93
thing, but the wording of the error message won't be exactly the same though.
â Kusalananda
Mar 23 at 17:15
3
3
[ t -eq 1]
may be true with some sh
implementations if a t
environment variable has been defined with a value that is an arithmetic expression that resolves to 1
. For instance, t=20/20 ksh93 -c '[ t -eq 1 ]'
is true. t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.â Stéphane Chazelas
Mar 23 at 17:06
[ t -eq 1]
may be true with some sh
implementations if a t
environment variable has been defined with a value that is an arithmetic expression that resolves to 1
. For instance, t=20/20 ksh93 -c '[ t -eq 1 ]'
is true. t='a[$(")]' ksh93 -c '[ t -eq 1 ]'
would give you a 'end of file' unexpected error.â Stéphane Chazelas
Mar 23 at 17:06
1
1
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
Having said that, I agree the DOS text file format is a much more likely explanation
â Stéphane Chazelas
Mar 23 at 17:11
@StéphaneChazelas Nicely done with that
ksh93
thing, but the wording of the error message won't be exactly the same though.â Kusalananda
Mar 23 at 17:15
@StéphaneChazelas Nicely done with that
ksh93
thing, but the wording of the error message won't be exactly the same though.â Kusalananda
Mar 23 at 17:15
add a comment |Â
up vote
0
down vote
Missing the shebang line #!/bin/sh
and t
isn't defined
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
add a comment |Â
up vote
0
down vote
Missing the shebang line #!/bin/sh
and t
isn't defined
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Missing the shebang line #!/bin/sh
and t
isn't defined
Missing the shebang line #!/bin/sh
and t
isn't defined
answered Mar 23 at 7:37
jas-
71038
71038
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
add a comment |Â
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
1
1
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
None of those things would provoke an "unexpected end of file" error.
â Kusalananda
Mar 23 at 7:52
add a comment |Â
up vote
0
down vote
- replace
#!
by#!/bin/sh
or runsh ./script.sh
, and you must set t as integer$t
nott
.
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
add a comment |Â
up vote
0
down vote
- replace
#!
by#!/bin/sh
or runsh ./script.sh
, and you must set t as integer$t
nott
.
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
add a comment |Â
up vote
0
down vote
up vote
0
down vote
- replace
#!
by#!/bin/sh
or runsh ./script.sh
, and you must set t as integer$t
nott
.
- replace
#!
by#!/bin/sh
or runsh ./script.sh
, and you must set t as integer$t
nott
.
edited Mar 23 at 17:09
Jeff Schaller
31.2k846105
31.2k846105
answered Mar 23 at 16:36
Linux-Programmer
71
71
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
add a comment |Â
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
The answer is spot on, but it could use with a bit of expansion on the reasons for it
â Bruno9779
Mar 23 at 16:46
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f433004%2fshell-script-giving-error%23new-answer', 'question_page');
);
Post as a guest
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
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
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
What's the output of
sed -n l < your-script
?â Stéphane Chazelas
Mar 23 at 17:11