What are these three extra chars and why do they cause such a strange error? [duplicate]












3
















This question already has an answer here:




  • #!/bin/bash - no such file or directory

    8 answers




Look at these two files:




  • File 1

  • File 2


They look to me entirely identical, but File 1 has 41 bytes and File 2 has 44 bytes.



Now, I would not care about 3 extra chars, however, I think these chars are also responsible to a strange error: when I clone and run these files, File 1 runs OK while File 2 returns an error on line 3: "./BasicCheck.sh: line 3: cd: case0 : No such file or directory".



So: what are these extra chars? Why do they cause errors? And what should I do to fix these errors?



My guess is that they are newlines - perhaps File 1 has Linux-based newlines and File 2 has Windows-based newlines. Is it correct? And why should it cause such errors?










share|improve this question













marked as duplicate by glenn jackman, mosvy, Gilles bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Mar 19 at 18:01


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 8





    Don't make us chase links. Post the text here, and highlight the differences.

    – glenn jackman
    Mar 19 at 15:18






  • 2





    @glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

    – Erel Segal-Halevi
    Mar 19 at 15:19








  • 6





    Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

    – glenn jackman
    Mar 19 at 15:21








  • 2





    Please also show exactly how you invoke these scripts.

    – glenn jackman
    Mar 19 at 15:21






  • 1





    One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

    – mosvy
    Mar 19 at 15:28
















3
















This question already has an answer here:




  • #!/bin/bash - no such file or directory

    8 answers




Look at these two files:




  • File 1

  • File 2


They look to me entirely identical, but File 1 has 41 bytes and File 2 has 44 bytes.



Now, I would not care about 3 extra chars, however, I think these chars are also responsible to a strange error: when I clone and run these files, File 1 runs OK while File 2 returns an error on line 3: "./BasicCheck.sh: line 3: cd: case0 : No such file or directory".



So: what are these extra chars? Why do they cause errors? And what should I do to fix these errors?



My guess is that they are newlines - perhaps File 1 has Linux-based newlines and File 2 has Windows-based newlines. Is it correct? And why should it cause such errors?










share|improve this question













marked as duplicate by glenn jackman, mosvy, Gilles bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Mar 19 at 18:01


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 8





    Don't make us chase links. Post the text here, and highlight the differences.

    – glenn jackman
    Mar 19 at 15:18






  • 2





    @glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

    – Erel Segal-Halevi
    Mar 19 at 15:19








  • 6





    Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

    – glenn jackman
    Mar 19 at 15:21








  • 2





    Please also show exactly how you invoke these scripts.

    – glenn jackman
    Mar 19 at 15:21






  • 1





    One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

    – mosvy
    Mar 19 at 15:28














3












3








3









This question already has an answer here:




  • #!/bin/bash - no such file or directory

    8 answers




Look at these two files:




  • File 1

  • File 2


They look to me entirely identical, but File 1 has 41 bytes and File 2 has 44 bytes.



Now, I would not care about 3 extra chars, however, I think these chars are also responsible to a strange error: when I clone and run these files, File 1 runs OK while File 2 returns an error on line 3: "./BasicCheck.sh: line 3: cd: case0 : No such file or directory".



So: what are these extra chars? Why do they cause errors? And what should I do to fix these errors?



My guess is that they are newlines - perhaps File 1 has Linux-based newlines and File 2 has Windows-based newlines. Is it correct? And why should it cause such errors?










share|improve this question















This question already has an answer here:




  • #!/bin/bash - no such file or directory

    8 answers




Look at these two files:




  • File 1

  • File 2


They look to me entirely identical, but File 1 has 41 bytes and File 2 has 44 bytes.



Now, I would not care about 3 extra chars, however, I think these chars are also responsible to a strange error: when I clone and run these files, File 1 runs OK while File 2 returns an error on line 3: "./BasicCheck.sh: line 3: cd: case0 : No such file or directory".



So: what are these extra chars? Why do they cause errors? And what should I do to fix these errors?



My guess is that they are newlines - perhaps File 1 has Linux-based newlines and File 2 has Windows-based newlines. Is it correct? And why should it cause such errors?





This question already has an answer here:




  • #!/bin/bash - no such file or directory

    8 answers








bash error-handling






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 19 at 15:13









Erel Segal-HaleviErel Segal-Halevi

305128




305128




marked as duplicate by glenn jackman, mosvy, Gilles bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Mar 19 at 18:01


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by glenn jackman, mosvy, Gilles bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Mar 19 at 18:01


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 8





    Don't make us chase links. Post the text here, and highlight the differences.

    – glenn jackman
    Mar 19 at 15:18






  • 2





    @glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

    – Erel Segal-Halevi
    Mar 19 at 15:19








  • 6





    Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

    – glenn jackman
    Mar 19 at 15:21








  • 2





    Please also show exactly how you invoke these scripts.

    – glenn jackman
    Mar 19 at 15:21






  • 1





    One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

    – mosvy
    Mar 19 at 15:28














  • 8





    Don't make us chase links. Post the text here, and highlight the differences.

    – glenn jackman
    Mar 19 at 15:18






  • 2





    @glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

    – Erel Segal-Halevi
    Mar 19 at 15:19








  • 6





    Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

    – glenn jackman
    Mar 19 at 15:21








  • 2





    Please also show exactly how you invoke these scripts.

    – glenn jackman
    Mar 19 at 15:21






  • 1





    One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

    – mosvy
    Mar 19 at 15:28








8




8





Don't make us chase links. Post the text here, and highlight the differences.

– glenn jackman
Mar 19 at 15:18





Don't make us chase links. Post the text here, and highlight the differences.

– glenn jackman
Mar 19 at 15:18




2




2





@glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

– Erel Segal-Halevi
Mar 19 at 15:19







@glennjackman that's exactly the point - there are no visible differences. If I copy the text from both links, they will appear exactly the same and there will be no way to find out the difference. This is why I give the links to the original files.

– Erel Segal-Halevi
Mar 19 at 15:19






6




6





Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

– glenn jackman
Mar 19 at 15:21







Run both scripts through od -c filename and you'll be shown the exact characters in the files. If one script has DOS-style newlines (with a 3 line file, that would account for the extra 3 bytes) then I would have expected a different error message. Or specifically, the same error message, but "garbled".

– glenn jackman
Mar 19 at 15:21






2




2





Please also show exactly how you invoke these scripts.

– glenn jackman
Mar 19 at 15:21





Please also show exactly how you invoke these scripts.

– glenn jackman
Mar 19 at 15:21




1




1





One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

– mosvy
Mar 19 at 15:28





One file has lines terminated by cr/lf (dos mode), the other just by lf (unix mode). The extra chars are carriage returns / r / CR / ascii 13.

– mosvy
Mar 19 at 15:28










1 Answer
1






active

oldest

votes


















11














The file command points out the issue:



% file file*
file1: Bourne-Again shell script, ASCII text executable
file2: Bourne-Again shell script, ASCII text executable, with CRLF line terminators


The second script is in "DOS" format. and so will not work as expected. You can convert it with dos2unix and the results are now the same



% dos2unix file2
dos2unix: converting file file2 to Unix format ...

% ls -l file1 file2
-rw-r--r-- 1 sweh sweh 41 Mar 19 11:23 file1
-rw-r--r-- 1 sweh sweh 41 Mar 19 11:25 file2


When you try to use a DOS format file with Unix commands, there is a trailing control-M at the end of every line. So a line such as



a=b


will really set a to b followed by control-M, shorthand ^M:



a=b^M


Every command will be similarly impacted; eg a simple line with the two-character command ls would try to run the three-character command ls<control-M>, which doesn't exist.






share|improve this answer
































    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    11














    The file command points out the issue:



    % file file*
    file1: Bourne-Again shell script, ASCII text executable
    file2: Bourne-Again shell script, ASCII text executable, with CRLF line terminators


    The second script is in "DOS" format. and so will not work as expected. You can convert it with dos2unix and the results are now the same



    % dos2unix file2
    dos2unix: converting file file2 to Unix format ...

    % ls -l file1 file2
    -rw-r--r-- 1 sweh sweh 41 Mar 19 11:23 file1
    -rw-r--r-- 1 sweh sweh 41 Mar 19 11:25 file2


    When you try to use a DOS format file with Unix commands, there is a trailing control-M at the end of every line. So a line such as



    a=b


    will really set a to b followed by control-M, shorthand ^M:



    a=b^M


    Every command will be similarly impacted; eg a simple line with the two-character command ls would try to run the three-character command ls<control-M>, which doesn't exist.






    share|improve this answer






























      11














      The file command points out the issue:



      % file file*
      file1: Bourne-Again shell script, ASCII text executable
      file2: Bourne-Again shell script, ASCII text executable, with CRLF line terminators


      The second script is in "DOS" format. and so will not work as expected. You can convert it with dos2unix and the results are now the same



      % dos2unix file2
      dos2unix: converting file file2 to Unix format ...

      % ls -l file1 file2
      -rw-r--r-- 1 sweh sweh 41 Mar 19 11:23 file1
      -rw-r--r-- 1 sweh sweh 41 Mar 19 11:25 file2


      When you try to use a DOS format file with Unix commands, there is a trailing control-M at the end of every line. So a line such as



      a=b


      will really set a to b followed by control-M, shorthand ^M:



      a=b^M


      Every command will be similarly impacted; eg a simple line with the two-character command ls would try to run the three-character command ls<control-M>, which doesn't exist.






      share|improve this answer




























        11












        11








        11







        The file command points out the issue:



        % file file*
        file1: Bourne-Again shell script, ASCII text executable
        file2: Bourne-Again shell script, ASCII text executable, with CRLF line terminators


        The second script is in "DOS" format. and so will not work as expected. You can convert it with dos2unix and the results are now the same



        % dos2unix file2
        dos2unix: converting file file2 to Unix format ...

        % ls -l file1 file2
        -rw-r--r-- 1 sweh sweh 41 Mar 19 11:23 file1
        -rw-r--r-- 1 sweh sweh 41 Mar 19 11:25 file2


        When you try to use a DOS format file with Unix commands, there is a trailing control-M at the end of every line. So a line such as



        a=b


        will really set a to b followed by control-M, shorthand ^M:



        a=b^M


        Every command will be similarly impacted; eg a simple line with the two-character command ls would try to run the three-character command ls<control-M>, which doesn't exist.






        share|improve this answer















        The file command points out the issue:



        % file file*
        file1: Bourne-Again shell script, ASCII text executable
        file2: Bourne-Again shell script, ASCII text executable, with CRLF line terminators


        The second script is in "DOS" format. and so will not work as expected. You can convert it with dos2unix and the results are now the same



        % dos2unix file2
        dos2unix: converting file file2 to Unix format ...

        % ls -l file1 file2
        -rw-r--r-- 1 sweh sweh 41 Mar 19 11:23 file1
        -rw-r--r-- 1 sweh sweh 41 Mar 19 11:25 file2


        When you try to use a DOS format file with Unix commands, there is a trailing control-M at the end of every line. So a line such as



        a=b


        will really set a to b followed by control-M, shorthand ^M:



        a=b^M


        Every command will be similarly impacted; eg a simple line with the two-character command ls would try to run the three-character command ls<control-M>, which doesn't exist.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 19 at 15:49









        Rich

        367212




        367212










        answered Mar 19 at 15:28









        Stephen HarrisStephen Harris

        27k35282




        27k35282















            Popular posts from this blog

            Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

            ComboBox Display Member on multiple fields

            Is it possible to collect Nectar points via Trainline?