/usr/bin/ls: /usr/bin/ls: cannot execute binary file
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I'm using git bash
on Windows. I want to run ls
command with bash
. I can run ls
separately like this:
$ ls
f1 f2
However, when I try with bash
, I get the error:
$ bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
But if I create my script it works fine:
$ echo "echo $@" > my.sh && bash my.sh
What can be the problem?
bash shell
add a comment |Â
up vote
2
down vote
favorite
I'm using git bash
on Windows. I want to run ls
command with bash
. I can run ls
separately like this:
$ ls
f1 f2
However, when I try with bash
, I get the error:
$ bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
But if I create my script it works fine:
$ echo "echo $@" > my.sh && bash my.sh
What can be the problem?
bash shell
3
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.
â ridgy
Feb 3 '17 at 16:39
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without-c
option and why it's needed forls
?
â Max Wizard K
Feb 3 '17 at 16:42
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm using git bash
on Windows. I want to run ls
command with bash
. I can run ls
separately like this:
$ ls
f1 f2
However, when I try with bash
, I get the error:
$ bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
But if I create my script it works fine:
$ echo "echo $@" > my.sh && bash my.sh
What can be the problem?
bash shell
I'm using git bash
on Windows. I want to run ls
command with bash
. I can run ls
separately like this:
$ ls
f1 f2
However, when I try with bash
, I get the error:
$ bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
But if I create my script it works fine:
$ echo "echo $@" > my.sh && bash my.sh
What can be the problem?
bash shell
bash shell
edited Feb 3 '17 at 16:59
Kusalananda
113k15217345
113k15217345
asked Feb 3 '17 at 16:30
Max Wizard K
502616
502616
3
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.
â ridgy
Feb 3 '17 at 16:39
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without-c
option and why it's needed forls
?
â Max Wizard K
Feb 3 '17 at 16:42
add a comment |Â
3
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.
â ridgy
Feb 3 '17 at 16:39
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without-c
option and why it's needed forls
?
â Max Wizard K
Feb 3 '17 at 16:42
3
3
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.â ridgy
Feb 3 '17 at 16:39
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.â ridgy
Feb 3 '17 at 16:39
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without
-c
option and why it's needed for ls
?â Max Wizard K
Feb 3 '17 at 16:42
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without
-c
option and why it's needed for ls
?â Max Wizard K
Feb 3 '17 at 16:42
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
10
down vote
accepted
From the fine manual for bash(1)
:
ARGUMENTS
If arguments remain after option processing, and neither the -c nor the
-s option has been supplied, the first argument is assumed to be the
name of a file containing shell commands.
Does ls
contain shell commands? No, it is a binary file. bash
squawks about this fact and fails.
A strace
may help show what is going on:
$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
The alog
file can get a bit messy, but shows bash
looking for ls
in the current working directoryâÂÂa security risk if someone has placed a naughty ls
file somewhere!âÂÂand then does a PATH
search:
$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
open("/usr/bin/ls", O_RDONLY) = 3
As to why this could be a security risk, if you run bash somecmd
from the wrong directory where someone has created a ls
(or some other known command due to a bug in a script):
$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus yourbash ls
is an example of an argument that remains, asbash
tried to read it as if it were a file of shell commands.
â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?bash -c -s
- these?
â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
From the fine manual for bash(1)
:
ARGUMENTS
If arguments remain after option processing, and neither the -c nor the
-s option has been supplied, the first argument is assumed to be the
name of a file containing shell commands.
Does ls
contain shell commands? No, it is a binary file. bash
squawks about this fact and fails.
A strace
may help show what is going on:
$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
The alog
file can get a bit messy, but shows bash
looking for ls
in the current working directoryâÂÂa security risk if someone has placed a naughty ls
file somewhere!âÂÂand then does a PATH
search:
$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
open("/usr/bin/ls", O_RDONLY) = 3
As to why this could be a security risk, if you run bash somecmd
from the wrong directory where someone has created a ls
(or some other known command due to a bug in a script):
$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus yourbash ls
is an example of an argument that remains, asbash
tried to read it as if it were a file of shell commands.
â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?bash -c -s
- these?
â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
add a comment |Â
up vote
10
down vote
accepted
From the fine manual for bash(1)
:
ARGUMENTS
If arguments remain after option processing, and neither the -c nor the
-s option has been supplied, the first argument is assumed to be the
name of a file containing shell commands.
Does ls
contain shell commands? No, it is a binary file. bash
squawks about this fact and fails.
A strace
may help show what is going on:
$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
The alog
file can get a bit messy, but shows bash
looking for ls
in the current working directoryâÂÂa security risk if someone has placed a naughty ls
file somewhere!âÂÂand then does a PATH
search:
$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
open("/usr/bin/ls", O_RDONLY) = 3
As to why this could be a security risk, if you run bash somecmd
from the wrong directory where someone has created a ls
(or some other known command due to a bug in a script):
$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus yourbash ls
is an example of an argument that remains, asbash
tried to read it as if it were a file of shell commands.
â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?bash -c -s
- these?
â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
add a comment |Â
up vote
10
down vote
accepted
up vote
10
down vote
accepted
From the fine manual for bash(1)
:
ARGUMENTS
If arguments remain after option processing, and neither the -c nor the
-s option has been supplied, the first argument is assumed to be the
name of a file containing shell commands.
Does ls
contain shell commands? No, it is a binary file. bash
squawks about this fact and fails.
A strace
may help show what is going on:
$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
The alog
file can get a bit messy, but shows bash
looking for ls
in the current working directoryâÂÂa security risk if someone has placed a naughty ls
file somewhere!âÂÂand then does a PATH
search:
$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
open("/usr/bin/ls", O_RDONLY) = 3
As to why this could be a security risk, if you run bash somecmd
from the wrong directory where someone has created a ls
(or some other known command due to a bug in a script):
$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$
From the fine manual for bash(1)
:
ARGUMENTS
If arguments remain after option processing, and neither the -c nor the
-s option has been supplied, the first argument is assumed to be the
name of a file containing shell commands.
Does ls
contain shell commands? No, it is a binary file. bash
squawks about this fact and fails.
A strace
may help show what is going on:
$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
The alog
file can get a bit messy, but shows bash
looking for ls
in the current working directoryâÂÂa security risk if someone has placed a naughty ls
file somewhere!âÂÂand then does a PATH
search:
$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", X_OK) = 0
stat("/usr/bin/ls", st_mode=S_IFREG) = 0
access("/usr/bin/ls", R_OK) = 0
open("/usr/bin/ls", O_RDONLY) = 3
As to why this could be a security risk, if you run bash somecmd
from the wrong directory where someone has created a ls
(or some other known command due to a bug in a script):
$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$
edited 8 mins ago
answered Feb 3 '17 at 16:55
thrig
23.3k12955
23.3k12955
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus yourbash ls
is an example of an argument that remains, asbash
tried to read it as if it were a file of shell commands.
â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?bash -c -s
- these?
â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
add a comment |Â
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus yourbash ls
is an example of an argument that remains, asbash
tried to read it as if it were a file of shell commands.
â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?bash -c -s
- these?
â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
thanks, can you elaborate a bit on this If arguments remain after option processing? An example maybe?
â Max Wizard K
Feb 3 '17 at 17:18
@Maximus your
bash ls
is an example of an argument that remains, as bash
tried to read it as if it were a file of shell commands.â thrig
Feb 3 '17 at 17:20
@Maximus your
bash ls
is an example of an argument that remains, as bash
tried to read it as if it were a file of shell commands.â thrig
Feb 3 '17 at 17:20
yeah, I understood that. If arguments remain after option processing - what option processing?
bash -c -s
- these?â Max Wizard K
Feb 3 '17 at 17:22
yeah, I understood that. If arguments remain after option processing - what option processing?
bash -c -s
- these?â Max Wizard K
Feb 3 '17 at 17:22
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
@Maximus yes, those are options. Some consume additional arguments.
â thrig
Feb 3 '17 at 17:31
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
got it, thanks, good luck
â Max Wizard K
Feb 3 '17 at 17:33
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%2f342309%2fusr-bin-ls-usr-bin-ls-cannot-execute-binary-file%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
3
bash -c ls
. From the manpage: If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, they are assigned to the positional parameters, starting with $0.â ridgy
Feb 3 '17 at 16:39
@ridgy, thanks, it works this way. I'm not very proficient with bash yet. Can you please post an elaborate answer and explain why it works with my custom script without
-c
option and why it's needed forls
?â Max Wizard K
Feb 3 '17 at 16:42