Remove “\r” from echoing out in bash script

Question

Here is my bash script that is sent a variable from php:

STRING1="/opt/lampp/htdocs/dev/img/$VAR1"
mv $STRING1 "/opt/lampp/htdocs/dev/newlocation/"

It, for some reason, places "\r" at the end of $STRING1 and can't find the file because it will be something of the form "my_picture.jpg\r"

Any help is appreciated!

Answer 1

Bash expects that end-of-line in a script is always and only a newline (\n) character, Unix-style, not a carriage return-newline combination (\r\n) like you normally see on Windows. Bash thinks the \r character is just an ordinary character at the end of the string. (Characters that follow a double quoted string are just concatenated onto the end.)

As Ignacio suggests, the solution is to fix your script to eliminate the \r characters. dos2unix is one way. Another would be to use tr -d '\r' < infile > outfile as a filter.

Answer 2

Pass the script through dos2unix to fix the newlines.

Answer 3

This is obviously for the purpose of other googlers like me, not the OP, seeing that it's been 5+ years. But this solution existed back then too.

You can try a bash substitution to strip the largest pattern from the end of the string which looks like ${varname%%pattern}, more here:

http://tldp.org/LDP/abs/html/string-manipulation.html

It should be faster than spawning another process like tr to handle it.

VARNAME=$'a_bad_filename\r'
VARNAME="${VARNAME%%[[:cntrl:]]}"

Here is a reference for the severely-limited bash pattern matching (it is not really regular expression, more of a 'like' or 'glob' expression). As to why the carriage return is in the control class and not the whitespace class, I'm not sure. It is considered white-space in other languages. Without enabling extended pattern matching via a "shopt -s extglob", there's no way to specify a simple construct like "this char repeated 0 or more times" in bash. I also found

printf "%q" "${VARNAME}"

.. in addition to set -vx to show/test for the carriage return.

I came across this problem when using cygwin bash against output from the standard (non-cygwin) version of python; I'm confused as to why I'm not seeing more on how to solve it.