I am creating a command file in windows using JavaScript activexobject.
This file will run on Mac after double click.
I am writing the file as
script.write("#!/bin/bash\r");
script.write('cd "$(dirname "$0")"\r');
The additional \r is for carriage return line ending in Mac.
But this doesn't work. The command doesn't execute just starts and over. No cd happens.
I am sure that this problem is related to line endings because when I edit the line ending (by deleting the newline and again add newline using return key) after opening the command file in Mac with TextEdit, it works.
How can I solve this in write method?
You should try writing '\n' instead of '\r'. Carriage returns were used in pre OSX machines only.
If you wanna visually see the line endings you could open up vim on the Mac and type :set list. All new lines will appear like $ and carriage returns as ^M. You should only be seeing $ if this is an OSX machine.
Related
When I paste text into the Terminal window, Terminal appends 0~ before the pasted string and 1~ after it. I've never seen this behaviour before. If I copy foo from anywhere (including the same Terminal window), pasting into the command line results in:
-bash-4.2$ 0~foo1~
I tried every method for pasting text into OS X terminal from How to paste into a terminal?, i.,e.
Command v; CommandControlv; Shift + Insert.
Pasting into text editors and browsers (basically, any place other than Terminal) does not add any extra characters. Why is this happening and how can I fix it?
I'm using macOS 10.14.2; Terminal version 2.9.1.
I don't know the actual answer for this but for me it works after restarting the terminal.
Command + Q
I will update once I will find something.
This question already has answers here:
Are shell scripts sensitive to encoding and line endings?
(14 answers)
Closed 5 years ago.
I'm using this tutorial to learn bash scripts to automate a few
tasks for me.
I'm connecting to a server using putty.
The script, located in .../Documents/LOG, is:
#!/bin/bash
# My first script
echo "Hello World!"
And I executed the following for read/write/execute permissions
chmod 755 my_script
Then, when I enter ./my_script, I'm getting the error given in the
title.
Some similar questions wanted to see these, so I think they might
help :
$ which bash
/bin/bash
and
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/bin/mh
I tried adding the current directory to PATH, but that doesn't
work …
Run following command in terminal
sed -i -e 's/\r$//' scriptname.sh
Then try
./scriptname.sh
It should work.
I have seen this issue when creating scripts in Windows env and then porting over to run on a Unix environment.
Try running dos2unix on the script:
http://dos2unix.sourceforge.net/
Or just rewrite the script in your Unix env using vi and test.
Unix uses different line endings so can't read the file you created on Windows. Hence it is seeing ^M as an illegal character.
If you want to write a file on Windows and then port over, make sure your editor is set to create files in UNIX format.
In notepad++ in the bottom right of the screen, it tells you the document format. By default, it will say Dos\Windows. To change it go to
settings->preferences
new document / default directory tab
select the format as unix and close
create a new document
If you use Sublime Text on Windows or Mac to edit your scripts:
Click on View > Line Endings > Unix and save the file again.
In notepad++ you can set it for the file specifically by pressing
Edit --> EOL Conversion --> UNIX/OSX Format
This is caused by editing file in windows and importing and executing in unix.
dos2unix -k -o filename should do the trick.
problem is with dos line ending. Following will convert it for unix
dos2unix file_name
NB: you may need to install dos2unix first with yum install dos2unix
another way to do it is using sed command to search and replace the dos line ending characters to unix format:
$sed -i -e 's/\r$//' your_script.sh
Your file has Windows line endings, which is confusing Linux.
Remove the spurious CR characters. You can do it with the following command:
$ sed -i -e 's/\r$//' setup.sh
For Eclipse users, you can either change the file encoding directly from the menu File > Convert Line Delimiters To > Unix (LF, \n, 0Α, ¶):
Or change the New text file line delimiter to Other: Unix on Window > Preferences > General > Workspace panel:
I was able to resolve the issue by opening the script in gedit and saving it with the proper Line Ending option:
File > Save As...
In the bottom left of the Save As prompt, there are drop-down menus for Character Encoding and Line Ending. Change the Line Ending from Windows to Unix/Linux then Save.
Atom has a built-in line ending selector package
More details here: https://github.com/atom/line-ending-selector
I develop on Windows and Mac/Linux at the same time and I avoid this ^M-error by simply running my scripts as I do in Windows:
$ php ./my_script
No need to change line endings.
I write my Perl code in Textpad (which I believe is only avai in Windows). I run it on Linux cmd prompt by calling the Perl interpreter explicitly, e.g. "perl script.pl". I was wondering if it's possible to run it simply as in "./script.pl". When I add the shebang in Windows, the Linux prompt complains "command not found", but it works fine if I call it with Perl, and also works fine after I dos2unix the script, so the issue seems to be the shebang not being parsed correctly. Any suggestions? Why does the rest of the Windows-formatted code work but not the shebang?
Your problem is that Windows prefers a different line ending convention (CRLF, or \r\n) than other operating systems (LF, or \n). Your editor is creating files with \r\n line endings by default.
The shebang is parsed by the operating system, which is not as forgiving as Perl about the stray \r at the end of the command. It tries to run /usr/bin/perl\r, which doesn't exist.
Your text editor should be able to save the script with Unix line-endings. This won't cause problems with using it on Windows, though a few Windows text editors (including Notepad) won't recognize the line endings properly. This will make it work properly on Linux.
The first line of your file is
#!/usr/bin/perl<CR><LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl<CR>. There is no such program. dos2unix changes the first line to
#!/usr/bin/perl<LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl and succeeds.
This question already has answers here:
Are shell scripts sensitive to encoding and line endings?
(14 answers)
Closed 5 years ago.
I'm using this tutorial to learn bash scripts to automate a few
tasks for me.
I'm connecting to a server using putty.
The script, located in .../Documents/LOG, is:
#!/bin/bash
# My first script
echo "Hello World!"
And I executed the following for read/write/execute permissions
chmod 755 my_script
Then, when I enter ./my_script, I'm getting the error given in the
title.
Some similar questions wanted to see these, so I think they might
help :
$ which bash
/bin/bash
and
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/bin/mh
I tried adding the current directory to PATH, but that doesn't
work …
Run following command in terminal
sed -i -e 's/\r$//' scriptname.sh
Then try
./scriptname.sh
It should work.
I have seen this issue when creating scripts in Windows env and then porting over to run on a Unix environment.
Try running dos2unix on the script:
http://dos2unix.sourceforge.net/
Or just rewrite the script in your Unix env using vi and test.
Unix uses different line endings so can't read the file you created on Windows. Hence it is seeing ^M as an illegal character.
If you want to write a file on Windows and then port over, make sure your editor is set to create files in UNIX format.
In notepad++ in the bottom right of the screen, it tells you the document format. By default, it will say Dos\Windows. To change it go to
settings->preferences
new document / default directory tab
select the format as unix and close
create a new document
If you use Sublime Text on Windows or Mac to edit your scripts:
Click on View > Line Endings > Unix and save the file again.
In notepad++ you can set it for the file specifically by pressing
Edit --> EOL Conversion --> UNIX/OSX Format
This is caused by editing file in windows and importing and executing in unix.
dos2unix -k -o filename should do the trick.
problem is with dos line ending. Following will convert it for unix
dos2unix file_name
NB: you may need to install dos2unix first with yum install dos2unix
another way to do it is using sed command to search and replace the dos line ending characters to unix format:
$sed -i -e 's/\r$//' your_script.sh
Your file has Windows line endings, which is confusing Linux.
Remove the spurious CR characters. You can do it with the following command:
$ sed -i -e 's/\r$//' setup.sh
For Eclipse users, you can either change the file encoding directly from the menu File > Convert Line Delimiters To > Unix (LF, \n, 0Α, ¶):
Or change the New text file line delimiter to Other: Unix on Window > Preferences > General > Workspace panel:
I was able to resolve the issue by opening the script in gedit and saving it with the proper Line Ending option:
File > Save As...
In the bottom left of the Save As prompt, there are drop-down menus for Character Encoding and Line Ending. Change the Line Ending from Windows to Unix/Linux then Save.
Atom has a built-in line ending selector package
More details here: https://github.com/atom/line-ending-selector
I develop on Windows and Mac/Linux at the same time and I avoid this ^M-error by simply running my scripts as I do in Windows:
$ php ./my_script
No need to change line endings.
I was wodnering why my emacs started putting ^m at the end of every line, i know how to "fix it" but i was wondering what caused it to happen. I have been using emacs in windows for some time now and it started more recently. Does anyone know why this starts?
Most likely the reason is that the buffer is using '...-unix' coding system when the file contains Windows carriage-return/linefeed line ends. The mode line will show you the coding system in use. See 'Coding Systems' in the Emacs Manual.
Ctrl-h C
will display the coding system currently in use.
I see this happening when the file contains both \r\n and \n\r line endings. That is, someone has written broken Windows line endings to the file (\n\r).
Go through your file and look for lines that start with ^M. This implies that the carriage return was after the newline character on the previous line, which is incorrect.
If that is the case, go back to the program that generated the file and make sure that it's writing correct Windows line endings.