Correct format for a command in Codenvy - bash

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.

Related

How to download a Shell script from Github with Unix formatting?

I am trying to share a Shell script from my Github with people. It is for a workshop and I thought the easiest way would be to have them download it with:
wget https://raw.githubusercontent.com/user/repo/master/script.sh
But I am getting this when I try to run it:
script.sh: line 2: $'\r': command not found
script.sh: line 4: $'\r': command not found
script.sh: line 6: $'\r': command not found
script.sh: line 7: syntax error near unexpected token `$'\r''
'cript.sh: line 7: `helpFunction()
However, it works when I convert it to Unix with dos2unix using:
dos2unix script.sh
How can I avoid having to use this extra step? I am also open to other suggestions about sharing my code in a simple way.

Shell script returns: run.sh: line 10: SET: command not found

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

Function not working in a bash script - error messages relate to '\r' [duplicate]

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.

Windows CRLF to Unix LF Issues in Vagrant

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.

Shell script can't be run in cygwin

I have a script as below:
# /brickos/util/f.sh
set folder=`pwd`
cd /brickos/boot
make
firmdl3 -f brickOS.srec
cd $folder
when I run it in cygwin(minty.exe), I got error as below, but when I run them in terminal directly, no any errors! what can I do?
$ f.sh
/cygdrive/c/cygwin/brickos/util/f.sh: line 2: cd: /brickos/boot
: No such file or directory
/cygdrive/c/cygwin/brickos/util/f.sh: line 3: $'make\r': command not found
firmdl3: ERROR- failed to open brickOS.srec
/cygdrive/c/cygwin/brickos/util/f.sh: line 5: cd:
: No such file or directory
$'make\r': command not found
suggests the script is saved with Windows (CRLF) instead of Unix style (just LF) line endings. Try converting it to Unix format and see if that improves matters.

Resources