I'm working on provisioning a few VMs using Vagrant. Here's the situation:
Host: Windows 7 (64-bit)
Guest: Ubuntu 14.04 (64-bit)
I am having an issue getting the CRLF line endings to convert to LFs. This is causing the bash scripts in the shared folder to fail within the guest machine (see below).
vagrant#vagrant-host:/vagrant/bin$ sudo bash build-ubuntu-14.04.1-c
make.sh
build-ubuntu-14.04.1-cmake.sh: line 5: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 19: $'\r': command not found
: invalid option04.1-cmake.sh: line 21: set: -
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
build-ubuntu-14.04.1-cmake.sh: line 22: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 24: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 26: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 29: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 36: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 42: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 46: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 48: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 50: $'\r': command not found
build-ubuntu-14.04.1-cmake.sh: line 226: syntax error: unexpected end of file
In my Vagrantfile I have set the shell privisioner parameter binary to false.
# Provision the VM
ubuntu.vm.provision "shell" do |s|
# replace Windows line endings with Unix line endings
s.binary = false
s.inline = "sudo apt-get update;
sudo bash vagrant/bin/build-ubuntu-14.04.1-cmake.sh"
end
As per the Vagrant documentation:
binary (boolean) - Vagrant automatically replaces Windows line endings with Unix line endings. If this is true, then Vagrant will not do this. By default this is "false". If the shell provisioner is communicating over WinRM, this defaults to "true".
What's the issue here? Am I overlooking something in the documentation?
Update 1:
I have tried to edit my local Git settings as recommended in this Stack Overflow answer, but no luck. Also, I have added a .gitattributes file to the root directory of the project and added the following to that file:
# detect all text files and automatically normalize them (convert CRLF to LF)
* text=auto
I have also read over "Dealing with line endings" document provided by Git. When I commit to my repository CRLFs are converted to LFs, but when I checkout changes in a Windows workspace the LFs are converted to CRLFs. This is the exact behavior I want in my Git workflow. The issue is with Vagrant. The binary flag that I set doesn't perform the way the documentation describes.
Update 2:
Changing s.binary = true fixed the issue. However, I think the wording in the documentation should be re-addressed. The documentation states that "If this [the flag] is true, then Vagrant will not do this [change CRLF to LF]." As I understand then, Vagrant will not change CRLFs to LFs if this flag is set. However, CRLFs are changed to LFs if this is set to true.
You're right, the documentation about binary was misleading. I've proposed a pull-request and this has been corrected on the documentation page.
So now it states:
binary (boolean) - Vagrant automatically replaces Windows line endings
with Unix line endings. If this is false, then Vagrant will not do
this. By default this is false. If the shell provisioner is
communicating over WinRM, this defaults to true.
So to replace Windows line endings (CRLF) with Unix line endings (LF) you need to set:
s.binary = true
Alternative solutions includes:
Changing line endings manually by:
using dos2unix command,
using ex command, e.g.
ex +'bufdo! %! tr -d \\r' -scxa *.sh
Add the following lines into your Bashrc file (e.g. ~/.bashrc)gist:
export SHELLOPTS
set -o igncr
If you're using Git for versioning your code, you should:
Configure Git on OS X to properly handle line endings by setting core.autocrlf option to input or false.
If you've installed Git On Windows, the most common mistake is to select Checkout Windows-style option during installation, so you should re-install it and choose either: Checkout as-is and commit Unix-style line endings (core.autocrlf is set to input) or Checkout as-is, commit as-is (core.autocrlf is set to false).
Consider creating git normalization file in your repository (.gitattributes) which ensures no CRLF line-endings are in place, neither on checkout nor on checkin, for example:
*.sh text eol=lf
So people editing your provisioning script, they won't break the line endings.
Read also: Dealing with line endings at GitHub Help.
Related: '\r': command not found - .bashrc / .bash_profile.
As was specified above in my update, changing s.binary = true fixed the issue. However, I think the wording in the documentation should be re-addressed. The documentation states that "If this [the flag] is true, then Vagrant will not do this [change CRLF to LF]." As I understand then, Vagrant will not change CRLFs to LFs if this flag is set. However, CRLFs are changed to LFs if this is set to true.
Perhaps completing the above:
September 2020, using Vagrant 2.2.10 on a Windows 10 computer, the default behaviour apparently is to try and replace Windows line endings. This however means that if you do use Linux line endings in your Vagrantfile - it will not work!
I was perplexed by getting several slightly different errors like
"Vagrantfile:1: syntax error, unexpected tIDENTIFIER,
expecting end-of-input [+ reference to different places in the Vagrantfile]"
By guesswork I finally got the idea to change my line endings FROM Linux LF TO Windows CR+LF, which made it all work.
TL;DR: Using Vagrant on windows, use Windows line endings (CR+LF) in your
Vagrantfiles.
Related
Codenvy is an IDE that removes all files that are in gitignore when the environment you work in goes to sleep. So every time I start working in Codenvy I need to put these files back. That is a hassle and therefore I am trying to add what in Codenvy is called a command (a script) for this.
I have the following:
1. cp vars-user-portal/variables.env user-portal/variables.env
2.
3. cp vars-user-portal/serviceAccountKey.json user-portal/serviceAccountKey.json
4.
5. cp vars-user-portal/.env user-portal/client/.env
6.
7. cd user-portal && npm install
8.
9. cd user-portal/client && npm install
10.
11. xdg-open user-portal/client/.env
When I run this command, I get the output:
/bin/bash: line 1: $'\r': command not found
/bin/bash: line 3: $'\r': command not found
/bin/bash: line 5: $'\r': command not found
Usage: npm <command>
...
Did you mean one of these?
install
uninstall
unstar
/bin/bash: line 7: $'\r': command not found
Usage: npm <command>
...
/bin/bash: line 9: $'\r': command not found
xdg-open: file '.env' does not exist
I have the impression that when there are spaces on a line it sees it as separate commands. Any idea how I can get this script to work?
Your file most likely has \r\n line endings, which should be changed to \n line endings.
A simple way to convert the file with the command line sed utility is as follows.
sed -i 's/\r\n/\n/g' "./path/to/file" (Untested).
In general, Windows applications terminate lines in text files with the 'carriage return' and 'line feed' characters, commonly written as the escape codes \r\n.
On the other hand, Unix-like systems terminate lines with only the line feed, or new as a line ending, which Unix uses just 'line feed' character \n.
See: http://www.cs.toronto.edu/~krueger/csc209h/tut/line-endings.html
Note:
As an additional mention, you should always add a shebang to the top of your script if it is to be executable, or else do not add one if it is to be solely sourced. #!/bin/bash for bash scripts, and #!/bin/sh for portable or POSIX-compliant scripts.
This question already has answers here:
running bash script in cygwin on windows 7 [duplicate]
(2 answers)
Are shell scripts sensitive to encoding and line endings?
(14 answers)
Closed 3 years ago.
I have windows, using Cygwin, trying to set JAVA_HOME permanently through my .bashrc file.
.bashrc:
export PATH="$JAVA_HOME/bin:$PATH"
export JAVA_HOME=$JAVA_HOME:"/cygdrive/c/Program Files (x86)/Java/jdk1.7.0_05"
.bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
running cygwin:
-bash: $'\377\376if': command not found
-bash: $'then\r': command not found
: No such file or directorysu//.bashrc
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: syntax error near unexpected token `fi'
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: `fi'
I am not sure if I took the commands from a tutorial that was meant for another system or if I am missing a step. Or whitespace is causing my commands not to run properly.
I've looked at multiple similar questions but I haven't found one where the question has my error exactly.
My home path:
$ echo $HOME
/cygdrive/c/Users/jhsu
$ echo ~
/cygdrive/c/Users/jhsu/
So I believe the files should be placed in the correct spot.
When all else fails in Cygwin...
Try running the dos2unix command on the file in question.
It might help when you see error messages like this:
-bash: '\r': command not found
Windows style newline characters can cause issues in Cygwin.
The dos2unix command modifies newline characters so they are Unix / Cygwin compatible.
CAUTION: the dos2unix command modifies files in place, so take precaution if necessary.
If you need to keep the original file, you should back it up first.
Note for Mac users: The dos2unix command does not exist on Mac OS X.
Check out this answer for a variety of solutions using different tools.
There is also a unix2dos command that does the reverse:
It modifies Unix newline characters so they're compatible with Windows tools.
If you open a file with Notepad and all the lines run together, try unix2dos filename.
For those who don't have dos2unix installed (and don't want to install it):
Remove trailing \r character that causes this error:
sed -i 's/\r$//' filename
Explanation:
Option -i is for in-place editing, we delete the trailing \r directly in the input file. Thus be careful to type the pattern correctly.
For WINDOWS (shell) users with Notepad++ (checked with v6.8.3) you can correct the specific file using the option
Edit
-> EOL conversion
-> Unix/OSX format
And save your file again.
Edit: still works in v7.5.1 (Aug 29 2017)
Edit: Jan 3, 2022. As VSCode is mentioned several times. Go to settings in VSCode and type files.eol in the search field and set to \n (Unix format). Note that this changes this setting for your user or workspace for all files and it may not be what you want. YMMV.
I am using cygwin and Windows7, the trick was NOT to put the set -o igncr into your .bashrc but put the whole SHELLOPTS into you environment variables under Windows. (So nothing with unix / cygwin...) I think it does not work from .bashrc because "the drops is already sucked"
as we would say in german. ;-)
So my SHELLOPTS looks like this
braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
SUBLIME TEXT
With sublime you just go to
View - > Line Endings -> (select)Unix
Then save the file. Will fix this issue.
Easy as that!
If you are using a recent Cygwin (e.g. 1.7), you can also start both your .bashrc and .bash_profile with the following line, on the first non commented line:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
(set -o igncr) 2>/dev/null && set -o igncr; # this comment is needed
This will force bash to ignore carriage return (\r) characters used in Windows line separators.
See http://cygwin.com/ml/cygwin-announce/2010-08/msg00015.html.
The error:
'\r': command not found
is caused by shell not able to recognise Windows-like CRLF line endings (0d 0a) as it expects only LF (0a).
Git
If you using Git on Windows, make sure you selected 'Checkout as-is' during setup. Then make sure that you run: git config --global core.autocrlf false, so Git will not perform any conversions when checking out or committing text files.
dos2unix
If you're not using Git, you simply need to convert these affected files/scripts back into Unix-like line endings (LF), either by:
dos2unix ~/.bashrc
Note: The dos2unix command is part of dos2unix package.
Ex/Vim editor + tr
If you've Vim installed, the following command should correct the files:
ex +'bufdo! %! tr -d \\r' -scxa ~/.bash*
Useful alias: alias dos2unix="ex +'bufdo! %! tr -d \\\\r' -scxa".
tr
Here is the method by using tr:
cat ~/.bashrc | tr -d '\r' > ~/.bashrc.fixed && mv -v ~/.bashrc.fixed ~/.bashrc
or:
tr -d '\r' < filename > new_filename
Note: The \r is equivalent to \015.
sed
You can try the following command:
sed -i'.bak' s/\r//g ~/.bash*
recode
The following aliases can be useful (which replaces dos2unix command):
alias unix2dos='recode lat1:ibmpc'
alias dos2unix='recode ibmpc:lat1'
Source: Free Unix Tools (ssh, bash, etc) under Windows.
perl
The following perl command can convert the file from DOS into Unix format:
perl -p -i.bak -e 's/\015//g' ~/.bash*
Source: stripping the ^M.
tofrodos
On Linux, like Ubuntu which doesn’t come standard with either dos2unix or unix2dos, you can install tofrodos package (sudo apt-get install tofrodos), and define the following aliases:
alias dos2unix=’fromdos’
alias unix2dos=’todos’
Then use in the same syntax as above.
Vagrant
If you're using Vagrant VM and this happens for provisioning script, try setting binary option to true:
# Shell provisioner, see: https://www.vagrantup.com/docs/provisioning/shell.html
config.vm.provision "shell" do |s|
s.binary = true # Replace Windows line endings with Unix line endings.
s.path = "script.sh"
end
See: Windows CRLF to Unix LF Issues in Vagrant.
try execution the following command
vim .bashrc
:set ff=unix
:wq!
You can also add the option -o igncr to the bash call, e.g.
bash -x -o igncr script.sh
As per this gist, the solution is to create a ~/.bash_profile (in HOME directory) that contains:
export SHELLOPTS
set -o igncr
May be you used notepad++ for creating/updating this file.
EOL(Edit->EOL Conversion) Conversion by default is Windows.
Change EOL Conversion in Notepad++
Edit -> EOL Conversion -> Unix (LF)
I had the same problem. Solution: I edit the file with pspad editor, and give it a unix format (Menu - Format -> UNIX)
I believe you can set this format to your file with many other editors
For the Emacs users out there:
Open the file
M-x set-buffer-file-coding-system
Select "unix"
This will update the new characters in the file to be unix style. More info on "Newline Representation" in Emacs can be found here:
http://ergoemacs.org/emacs/emacs_line_ending_char.html
Note: The above steps could be made into an Emacs script if one preferred to execute this from the command line.
Issue maybe occured because of the file/script created/downloaded from a windows machine. Please try converting into linux file format.
dos2unix ./script_name.sh
or
dos2unix ~/.bashrc
If you have the vim package installed on your Cygwin install, you can use vim to fix this without find & replace. Start vim as follows: vim filename.sh (often it is aliased to vi also). Then, type :set fileformat=unix, then :wq (write & quit) to save your changes. (The : puts you in vim's edit mode.)
I recommend this over dos2unix since vim is probably more commonly installed.
However, it is probably a best practice to set your text editor to save files that you plan to use in a Unix/Linux environment to have a Unix text format. The answers given above for Notepad++ are a good example.
Additional note: If you are unsure what type a file is (DOS or Unix), you may use the file filename.sh. This can especially help in debugging more obscure issues (such as encoding issues when importing SQL dumps that come from Windows).
For other options on how to modify text file formatting, see this IU knowledge base article
More background information on Bash scripts and line endings is found on this StackOverflow question.
In EditPlus you do this from the
Document → File Format (CR/LF) → Change File Format... menu and then choose the Unix / Mac OS X radio button.
1. Choice
EditorConfig — is my choice.
2. Relevance
This answer is relevant for March 2018. In the future, the data from this answer may be obsolete.
Author of this answer personally used EditorConfig at March 2018.
3. Limitations
You need to use one of supported IDE/editors.
4. Argumentation
Simply usage. I need set my .editorconfig file 1 time, where I create my project, → I can forget some platform-, style- and IDE-specific problems.
Cross-platform, cross-languages, cross-IDE, cross-editors.
5. Example
5.1. Simple
I install EditorConfig plugin for Sublime Text → my text editor. I edit files in Sublime Text.
For example, I have sashacrlf.sh file:
echo "Sasha" &
echo "Goddess!" &
I run this file in Cygwin:
$ bash sashacrlf.sh
Sasha
sashacrlf.sh: line 1: $'\r': command not found
Goddess!
I create a file .editorconfig in same project as sashacrlf.sh.
[*.sh]
end_of_line = lf
It means, that if you save any file with .sh extension in your project in your editor, EditorConfig set UNIX line endings for this file.
I save sashacrlf.sh in my text editor again. I run sashacrlf.sh again:
$ bash sashacrlf.sh
Sasha
Goddess!
I can't get unexpected output in console.
5.2. Multiple file extensions
For example, I want to have UNIX line endings in all files with extensions .sh, .bashrc and .bash_profile.
I add these lines to my .editorconfig file:
[*.{sh,bashrc,bash_profile}]
end_of_line = lf
Now, if I save any file with .sh, .bashrc or .bash_profile extension, EditorConfig automatically set UNIX line ending for this file.
6. Additional links
EditorConfig official site.
I'm trying to run a shell script so I can boot up my local version of a Meteor app that I'm working on. I've never used shell scripts before this, but got the thing running when I was working with the head developer. So this is my run.sh file:
#echo off
c:
cd /Users/ten3/Desktop/git/ten/website/prospect-recovery/prospect-recovery
SET ROOT_URL=http://localhost
SET SPECIAL_RUN=no
SET NO_BATCH=no
SET NO_MAIL=no
SET MAIL_GUN_TEST=yes
SET MAIL_THROTTLE_INTERVAL=0
SET NODE_OPTIONS=%1
SET SHORT_URL=http://sota.ddns.net
SET NODE_PATH=%AppData%\npm
meteor --port 80
echo “works”
I'm pretty clueless as to what these actually do, aside from keep my local copy of the app interacting with other APIs. Every time I try to run the script I get:
run.sh: line 4: #echo: command not found
run.sh: line 6: c:: command not found
run.sh: line 10: SET: command not found
run.sh: line 12: SET: command not found
run.sh: line 14: SET: command not found
run.sh: line 16: SET: command not found
run.sh: line 18: SET: command not found
run.sh: line 20: SET: command not found
run.sh: line 22: SET: command not found
run.sh: line 24: SET: command not found
run.sh: line 26: SET: command not found
Error: listen EACCES
“works”
I've tried changing the file permissions, using sudo, tried including the file location in the paths it looks for it, tried including bash within my file, tried running the file inside the directory run.sh is, pretty much everything I can google. I can't figure out what I'm missing, and would like to die.
You should rewrite it for bash or another shell for a unix-like operating system (there're many alternatives, with bash is the most common).
#!/bin/sh
cd /some/required/path
ROOT_URL='http://localhost'
SPECIAL_RUN='no'
...
NODE_OPTIONS="$1" # notice double quotes, single quotes don't perform $variable expansion
SHORT_URL="http://sota.ddns.net"
NODE_PATH=/actual/path/to/npm
export ROOT_URL SPECIAL_RUN ... NODE_OPTIONS SHORT_URL NODE_PATH
./meteor --port 80 # since the port is below 1024, it's privileged, and the script should be run from root. Use ports > 1024 to run as a user
To run a program or a script from a given directory, you may specify a /full/path/to/the/program or simply include /path/to/the to PATH. By default current directory isn't in PATH for security reasons (unlike in Windows).
This question already has answers here:
Convert DOS/Windows line endings to Linux line endings in Vim
(28 answers)
Closed 7 years ago.
I have recently installed a fresh version of Debian. I created this simple script:
#!/bin/bash
print_something () {
echo Hello I am a function
}
print_something
print_something
However this displays this error upon me issuing bash test.sh:
test.sh: line 3: $'\r': command not found
test.sh: line 4: syntax error near unexpected token `$'{\r''
'est.sh: line 4: `print_something () {
What am I doing wrong?
Many thanks!
Diagnosing:
Unix utilities in general expect line endings to be \n only, and usually break or show unexpected behavior and output with files that have Windows-style \r\n line endings - as bash does here.
Error messages containing the string \r are an indicator that such Windows-style line endings are present.
Passing a file to cat -v and examining the output for ^M at the end of output lines (which is how \r chars. are represented) is a way to check a file for Windows-style line endings on demand.
Fixing:
To convert a file with Windows-style line endings to Unix-style ones:
use the dos2unix utility, if already installed (typically, it is not), or installing it is an option; how you install it depends on your platform; e.g.:
on Ubuntu: sudo apt-get install dos2unix
on OSX, with Homebrew installed, brew install dos2unix
alternatively, use standard utilities to perform the conversion; there are several options; e.g.:
sed $'s/\r$//' win.txt > unix.txt
awk 'sub("\r$", "")+1' win.txt > unix.txt
There are variants of the above commands that update a file in place, but they're platform-specific, if available at all.
Make sure that the editor you use to create shell scripts / files for use with Unix utilities is configured to use Unix-style line endings.
I resolved the issue by installing dos2unix and then converting the file.
Many thanks to mklement0 who pointed this out.
This question already has answers here:
running bash script in cygwin on windows 7 [duplicate]
(2 answers)
Are shell scripts sensitive to encoding and line endings?
(14 answers)
Closed 3 years ago.
I have windows, using Cygwin, trying to set JAVA_HOME permanently through my .bashrc file.
.bashrc:
export PATH="$JAVA_HOME/bin:$PATH"
export JAVA_HOME=$JAVA_HOME:"/cygdrive/c/Program Files (x86)/Java/jdk1.7.0_05"
.bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
running cygwin:
-bash: $'\377\376if': command not found
-bash: $'then\r': command not found
: No such file or directorysu//.bashrc
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: syntax error near unexpected token `fi'
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: `fi'
I am not sure if I took the commands from a tutorial that was meant for another system or if I am missing a step. Or whitespace is causing my commands not to run properly.
I've looked at multiple similar questions but I haven't found one where the question has my error exactly.
My home path:
$ echo $HOME
/cygdrive/c/Users/jhsu
$ echo ~
/cygdrive/c/Users/jhsu/
So I believe the files should be placed in the correct spot.
When all else fails in Cygwin...
Try running the dos2unix command on the file in question.
It might help when you see error messages like this:
-bash: '\r': command not found
Windows style newline characters can cause issues in Cygwin.
The dos2unix command modifies newline characters so they are Unix / Cygwin compatible.
CAUTION: the dos2unix command modifies files in place, so take precaution if necessary.
If you need to keep the original file, you should back it up first.
Note for Mac users: The dos2unix command does not exist on Mac OS X.
Check out this answer for a variety of solutions using different tools.
There is also a unix2dos command that does the reverse:
It modifies Unix newline characters so they're compatible with Windows tools.
If you open a file with Notepad and all the lines run together, try unix2dos filename.
For those who don't have dos2unix installed (and don't want to install it):
Remove trailing \r character that causes this error:
sed -i 's/\r$//' filename
Explanation:
Option -i is for in-place editing, we delete the trailing \r directly in the input file. Thus be careful to type the pattern correctly.
For WINDOWS (shell) users with Notepad++ (checked with v6.8.3) you can correct the specific file using the option
Edit
-> EOL conversion
-> Unix/OSX format
And save your file again.
Edit: still works in v7.5.1 (Aug 29 2017)
Edit: Jan 3, 2022. As VSCode is mentioned several times. Go to settings in VSCode and type files.eol in the search field and set to \n (Unix format). Note that this changes this setting for your user or workspace for all files and it may not be what you want. YMMV.
I am using cygwin and Windows7, the trick was NOT to put the set -o igncr into your .bashrc but put the whole SHELLOPTS into you environment variables under Windows. (So nothing with unix / cygwin...) I think it does not work from .bashrc because "the drops is already sucked"
as we would say in german. ;-)
So my SHELLOPTS looks like this
braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
SUBLIME TEXT
With sublime you just go to
View - > Line Endings -> (select)Unix
Then save the file. Will fix this issue.
Easy as that!
If you are using a recent Cygwin (e.g. 1.7), you can also start both your .bashrc and .bash_profile with the following line, on the first non commented line:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
(set -o igncr) 2>/dev/null && set -o igncr; # this comment is needed
This will force bash to ignore carriage return (\r) characters used in Windows line separators.
See http://cygwin.com/ml/cygwin-announce/2010-08/msg00015.html.
The error:
'\r': command not found
is caused by shell not able to recognise Windows-like CRLF line endings (0d 0a) as it expects only LF (0a).
Git
If you using Git on Windows, make sure you selected 'Checkout as-is' during setup. Then make sure that you run: git config --global core.autocrlf false, so Git will not perform any conversions when checking out or committing text files.
dos2unix
If you're not using Git, you simply need to convert these affected files/scripts back into Unix-like line endings (LF), either by:
dos2unix ~/.bashrc
Note: The dos2unix command is part of dos2unix package.
Ex/Vim editor + tr
If you've Vim installed, the following command should correct the files:
ex +'bufdo! %! tr -d \\r' -scxa ~/.bash*
Useful alias: alias dos2unix="ex +'bufdo! %! tr -d \\\\r' -scxa".
tr
Here is the method by using tr:
cat ~/.bashrc | tr -d '\r' > ~/.bashrc.fixed && mv -v ~/.bashrc.fixed ~/.bashrc
or:
tr -d '\r' < filename > new_filename
Note: The \r is equivalent to \015.
sed
You can try the following command:
sed -i'.bak' s/\r//g ~/.bash*
recode
The following aliases can be useful (which replaces dos2unix command):
alias unix2dos='recode lat1:ibmpc'
alias dos2unix='recode ibmpc:lat1'
Source: Free Unix Tools (ssh, bash, etc) under Windows.
perl
The following perl command can convert the file from DOS into Unix format:
perl -p -i.bak -e 's/\015//g' ~/.bash*
Source: stripping the ^M.
tofrodos
On Linux, like Ubuntu which doesn’t come standard with either dos2unix or unix2dos, you can install tofrodos package (sudo apt-get install tofrodos), and define the following aliases:
alias dos2unix=’fromdos’
alias unix2dos=’todos’
Then use in the same syntax as above.
Vagrant
If you're using Vagrant VM and this happens for provisioning script, try setting binary option to true:
# Shell provisioner, see: https://www.vagrantup.com/docs/provisioning/shell.html
config.vm.provision "shell" do |s|
s.binary = true # Replace Windows line endings with Unix line endings.
s.path = "script.sh"
end
See: Windows CRLF to Unix LF Issues in Vagrant.
try execution the following command
vim .bashrc
:set ff=unix
:wq!
You can also add the option -o igncr to the bash call, e.g.
bash -x -o igncr script.sh
As per this gist, the solution is to create a ~/.bash_profile (in HOME directory) that contains:
export SHELLOPTS
set -o igncr
May be you used notepad++ for creating/updating this file.
EOL(Edit->EOL Conversion) Conversion by default is Windows.
Change EOL Conversion in Notepad++
Edit -> EOL Conversion -> Unix (LF)
I had the same problem. Solution: I edit the file with pspad editor, and give it a unix format (Menu - Format -> UNIX)
I believe you can set this format to your file with many other editors
For the Emacs users out there:
Open the file
M-x set-buffer-file-coding-system
Select "unix"
This will update the new characters in the file to be unix style. More info on "Newline Representation" in Emacs can be found here:
http://ergoemacs.org/emacs/emacs_line_ending_char.html
Note: The above steps could be made into an Emacs script if one preferred to execute this from the command line.
Issue maybe occured because of the file/script created/downloaded from a windows machine. Please try converting into linux file format.
dos2unix ./script_name.sh
or
dos2unix ~/.bashrc
If you have the vim package installed on your Cygwin install, you can use vim to fix this without find & replace. Start vim as follows: vim filename.sh (often it is aliased to vi also). Then, type :set fileformat=unix, then :wq (write & quit) to save your changes. (The : puts you in vim's edit mode.)
I recommend this over dos2unix since vim is probably more commonly installed.
However, it is probably a best practice to set your text editor to save files that you plan to use in a Unix/Linux environment to have a Unix text format. The answers given above for Notepad++ are a good example.
Additional note: If you are unsure what type a file is (DOS or Unix), you may use the file filename.sh. This can especially help in debugging more obscure issues (such as encoding issues when importing SQL dumps that come from Windows).
For other options on how to modify text file formatting, see this IU knowledge base article
More background information on Bash scripts and line endings is found on this StackOverflow question.
In EditPlus you do this from the
Document → File Format (CR/LF) → Change File Format... menu and then choose the Unix / Mac OS X radio button.
1. Choice
EditorConfig — is my choice.
2. Relevance
This answer is relevant for March 2018. In the future, the data from this answer may be obsolete.
Author of this answer personally used EditorConfig at March 2018.
3. Limitations
You need to use one of supported IDE/editors.
4. Argumentation
Simply usage. I need set my .editorconfig file 1 time, where I create my project, → I can forget some platform-, style- and IDE-specific problems.
Cross-platform, cross-languages, cross-IDE, cross-editors.
5. Example
5.1. Simple
I install EditorConfig plugin for Sublime Text → my text editor. I edit files in Sublime Text.
For example, I have sashacrlf.sh file:
echo "Sasha" &
echo "Goddess!" &
I run this file in Cygwin:
$ bash sashacrlf.sh
Sasha
sashacrlf.sh: line 1: $'\r': command not found
Goddess!
I create a file .editorconfig in same project as sashacrlf.sh.
[*.sh]
end_of_line = lf
It means, that if you save any file with .sh extension in your project in your editor, EditorConfig set UNIX line endings for this file.
I save sashacrlf.sh in my text editor again. I run sashacrlf.sh again:
$ bash sashacrlf.sh
Sasha
Goddess!
I can't get unexpected output in console.
5.2. Multiple file extensions
For example, I want to have UNIX line endings in all files with extensions .sh, .bashrc and .bash_profile.
I add these lines to my .editorconfig file:
[*.{sh,bashrc,bash_profile}]
end_of_line = lf
Now, if I save any file with .sh, .bashrc or .bash_profile extension, EditorConfig automatically set UNIX line ending for this file.
6. Additional links
EditorConfig official site.