I have a short shell script that I wrote to just create backups.
#!/bin/bash
export MyBackup="MyBackup`date +%m-%d-%H:%M`"
echo $MyBackup
vi /tmp/$MyBackup.txt
rm -rf /tmp/"$MyBackup"
However, the filename that is created is something like MyBackup12-09-08:46?.txt?. The echo command returns the correct string, but the vi command creates a file with ?'s. How do I create the file without these?
Most of the issues ive lookedu p seem to talk about encoding differences, but I would think it would display incorrectly when I echoed if that was the case.
Thanks
Replace vi with touch to just create an empty file.
I ran e ++ff=unix and it seems like each one of the lines has a ^M at the end of them, so I removed them.
Is it possible to configure VIM in a such way that if I type
vim filename:123:89
it opens file filename goes to line 123 and column 89?
If not through VIM maybe with a hack for the shell?
You can install the file-line plugin to open a file to the line and column specified after the filename. (github mirror)
From the Readme on github
When you open a file:line, for instance when coping and pasting from
an error from your compiler vim tries to open a file with a colon in
its name.
Examples:
vim index.html:20
vim app/models/user.rb:1337
With this little script in your plugins folder if the stuff after the colon is a number and a file exists with the name especified before the colon vim will open this file and take you to the line you wished in the first place.
I'm not sure how to skip to the column, but I've wanted the same feature for ages, so I just hacked up the "jump to line" functionality. In your .bashrc, set
VIM=$(which vim)
function vim {
local args
IFS=':' read -a args <<< "$1"
"$VIM" "${args[0]}" +0"${args[1]}"
}
This splits the argument to Vim by :, then constructs a command line of the form
vim <filename> +0<line>
The +0 is a hack to make sure the default line number is zero.
(If you're not using Bash, you can adapt this into a script and put it in your path, or translate it to your favorite shell language. To edit filename:with:colons, use $VIM.)
I've been using the file-line plugin, but it has a few open issues, and breaks some other vim plugins. So I went fishing for a better solution. Here it is:
function vim() {
local first="$1"
case $first in
*:*)
shift
command vim ${first%%:*} +0${first##*:} $#
;;
*)
command vim $#
;;
esac
}
Limitations:
bash only
Only parses first argument, whereas vim +X parses the first file argument. A more complex version could easily be made with proper command line parsing.
Advantages:
doesn't break other vim plugins
you could easily use $EDITOR and use this with emacs for instance.
compared to Fred's answer it doesn't use IFS/read to parse the argument but uses bash parameter expansion.
also sends in the remaining argument, which might occasionally be necessary.
I used the bash commands to append several lines to multiple configuration files:
> for filename in *.ovpn; do
> printf 'configurationscript-security 2\nup /etc/openvpn/update-resolv-conf\ndown /etc/openvpn/update-resolv-conf' >> $filename;
> done
However the control character "^M" appeared at end of each line in the configuration file:
I opened the files in vim, the files before bash commands looked like as folows:
I am curious why "^M" appears at end of each line? Thanks.
It is Windows' carriage return, use dos2unix to convert file. Vim recognize the file format and displays it correctly.
The ^M can also be removed via a regular expression in vim, if dos2unix isn't available.
:%s/^M//g, which can be entered as: Esc:%s/ctrl+Vctrl+M//g
Not sure why this has occurred for you with just a simple printf command on a linux system, maybe have a look that you're picking up the correct version of printf. I've given this a go on a linux system, and the local printf keeps the correct line-endings, as you would expect.
we are working on windows machine and code is deployed in linux.
Some how while developing some linux scripts we have some ctrl-m character. release is provided to customer.
what can be the impact on ctrl-m characters in shell scripts.
nus
open the file in vi editor
press escape and type below on command line in the file.
:%s/^M//g
make sure ^M is added by hitting Cntrl key + V + M then hit enter
it will remove the characters and you can save the file.
It will change the shebang line, so that the interpreter isn't found.
$ ./t.sh
bash: ./t.sh: /bin/bash^M: bad interpreter: No such file or directory
The ^M characters are carriage returns. Windows and DOS terminate lines of text with CR (^M, or ASCII code 13) followed by LF (^J, or linefeed, ASCII code 10). Linux uses just LF, so the carriage returns appear as part of the text and are interpreted as such. That means they'll break scripts.
Most linux distributions come with a utility called dos2unix pre-installed. You can use it to convert the end-of-line characters from DOS style to linux style.
Some editors will do the conversion automatically for you; others have options that let you specify which mode to use.
You can use the below syntax too. Since in windows, this Control+v+m will not work , you can use \r instead.
Open the file in binary mode to view the Control-M characters using vim editor with -b option and use the below command to replace the Control-M characters
%s#\r##g
You could use the following script to clean up ^M from files in a directory.
for file in $(find path/to/your/files -type f); do
tr -d '\r' <$file >temp.$$ && mv temp.$$ $file
done
Every time I run a script using bash scriptname.sh from the command line in Debian, I get Command Not found and then the result of the script.
The script works but there is always a Command Not Found statement printed on screen for each empty line. Each blank line is resulting in a command not found.
I am running the script from the /var folder.
Here is the script:
#!/bin/bash
echo Hello World
I run it by typing the following:
bash testscript.sh
Why would this occur?
Make sure your first line is:
#!/bin/bash
Enter your path to bash if it is not /bin/bash
Try running:
dos2unix script.sh
That wil convert line endings, etc from Windows to unix format. i.e. it strips \r (CR) from line endings to change them from \r\n (CR+LF) to \n (LF).
More details about the dos2unix command (man page)
Another way to tell if your file is in dos/Win format:
cat scriptname.sh | sed 's/\r/<CR>/'
The output will look something like this:
#!/bin/sh<CR>
<CR>
echo Hello World<CR>
<CR>
This will output the entire file text with <CR> displayed for each \r character in the file.
You can use bash -x scriptname.sh to trace it.
I also ran into a similar issue. The issue seems to be permissions. If you do an ls -l, you may be able to identify that your file may NOT have the execute bit turned on. This will NOT allow the script to execute. :)
As #artooro added in comment:
To fix that issue run chmod +x testscript.sh
This might be trivial and not related to the OP's question, but I often made this mistaken at the beginning when I was learning scripting
VAR_NAME = $(hostname)
echo "the hostname is ${VAR_NAME}"
This will produce 'command not found' response. The correct way is to eliminate the spaces
VAR_NAME=$(hostname)
On Bash for Windows I've tried incorrectly to run
run_me.sh
without ./ at the beginning and got the same error.
For people with Windows background the correct form looks redundant:
./run_me.sh
If the script does its job (relatively) well, then it's running okay. Your problem is probably a single line in the file referencing a program that's either not on the path, not installed, misspelled, or something similar.
One way is to place a set -x at the top of your script or run it with bash -x instead of just bash - this will output the lines before executing them and you usually just need to look at the command output immediately before the error to see what's causing the problem
If, as you say, it's the blank lines causing the problems, you might want to check what's actaully in them. Run:
od -xcb testscript.sh
and make sure there's no "invisible" funny characters like the CTRL-M (carriage return) you may get by using a Windows-type editor.
use dos2unix on your script file.
for executing that you must provide full path of that
for example
/home/Manuel/mywrittenscript
Try chmod u+x testscript.sh
I know it from here:
http://www.linuxquestions.org/questions/red-hat-31/running-shell-script-command-not-found-202062/
If you have Notepad++ and you get this .sh Error Message: "command not found"
or this autoconf Error Message "line 615:
../../autoconf/bin/autom4te: No such file or directory".
On your Notepad++, Go to Edit -> EOL Conversion then check Macinthos(CR).
This will edit your files. I also encourage to check all files with this command,
because soon such an error will occur.
Had the same problem. Unfortunately
dos2unix winfile.sh
bash: dos2unix: command not found
so I did this to convert.
awk '{ sub("\r$", ""); print }' winfile.sh > unixfile.sh
and then
bash unixfile.sh
Problems with running scripts may also be connected to bad formatting of multi-line commands, for example if you have a whitespace character after line-breaking "\". E.g. this:
./run_me.sh \
--with-some parameter
(please note the extra space after "\") will cause problems, but when you remove that space, it will run perfectly fine.
I was also having some of the Cannot execute command. Everything looked correct, but in fact I was having a non-breakable space right before my command which was ofcourse impossible to spot with the naked eye:
if [[ "true" ]]; then
highlight --syntax js "var i = 0;"
fi
Which, in Vim, looked like:
if [[ "true" ]]; then
highlight --syntax js "var i = 0;"
fi
Only after running the Bash script checker shellcheck did I find the problem.
I ran into this today, absentmindedly copying the dollar command prompt $ (ahead of a command string) into the script.
Make sure you haven´t override the 'PATH' variable by mistake like this:
#!/bin/bash
PATH="/home/user/Pictures/"; # do NOT do this
This was my mistake.
Add the current directory ( . ) to PATH to be able to execute a script, just by typing in its name, that resides in the current directory:
PATH=.:$PATH
You may want to update you .bashrc and .bash_profile files with aliases to recognize the command you are entering.
.bashrc and .bash_profile files are hidden files probably located on your C: drive where you save your program files.