/usr/bin/ls: /usr/bin/ls: cannot execute binary file

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite
1












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?










share|improve this question



















  • 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 for ls?
    – Max Wizard K
    Feb 3 '17 at 16:42














up vote
2
down vote

favorite
1












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?










share|improve this question



















  • 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 for ls?
    – Max Wizard K
    Feb 3 '17 at 16:42












up vote
2
down vote

favorite
1









up vote
2
down vote

favorite
1






1





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 for ls?
    – Max Wizard K
    Feb 3 '17 at 16:42












  • 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 for ls?
    – 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










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 /
$





share|improve this answer






















  • 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










  • 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










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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


















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






























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 /
$





share|improve this answer






















  • 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










  • 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














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 /
$





share|improve this answer






















  • 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










  • 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












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 /
$





share|improve this answer














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 /
$






share|improve this answer














share|improve this answer



share|improve this answer








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 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











  • @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










  • @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











  • @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

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay