$'\r': command not found — file encoding on CentosOS trough cPanel for cloud service

Question

I am writing a silly script trough cPanel on a Centoss remote server, no so much I can do about it, the script need changes from time to time, and upload trough ftp each time get annoying because of the process.

(that script is running on cron, directly from the system without us been able to change it; and yes, we probably should switch could provider, but not now in out hands)

for each empty line, it returns me the $'\r': command not found meaning that the editor add those crapy end lines, so I have to overcome it by placing a hash (coment) on each empty line. However this raise another errors as "unexpected end of file", etc...

I am sure 99.99% is due to the codification the online editor saves the file... (and again, we are basically forced to use this editor)

the editor, it allows to use all those encodings:

- ansi_x3.110-1983
- ansi_x3.4-1968
- armscii-8
- asmo_449
- big5
- big5-hkscs
- brf
- bs_4730
- bs_viewdata
- cp10007
- cp1125
- cp1250
- cp1253
- cp1254
- cp1255
- cp1256
- cp1257
- cp1258
- cp737
- cp770
- cp771
- cp772
- cp773
- cp774
- cp775
- csa_z243.4-1985-1
- csa_z243.4-1985-2
- csa_z243.4-1985-gr
- csn_369103
- cwi
- dec-mcs
- din_66003
- ds_2089
- ebcdic-at-de
- ebcdic-at-de-a
- ebcdic-ca-fr
- ebcdic-dk-no
- ebcdic-dk-no-a
- ebcdic-es
- ebcdic-es-a
- ebcdic-es-s
- ebcdic-fi-se
- ebcdic-fi-se-a
- ebcdic-fr
- ebcdic-is-friss
- ebcdic-it
- ebcdic-pt
- ebcdic-uk
- ebcdic-us
- ecma-cyrillic
- es
- es2
- euc-jisx0213
- euc-jp
- euc-jp-ms
- euc-kr
- euc-tw
- gb18030
- gb2312
- gb_1988-80
- gbk
- georgian-academy
- georgian-ps
- gost_19768-74
- greek-ccitt
- greek7
- greek7-old
- gsm03.38
- hp-greek8
- hp-roman8
- hp-roman9
- hp-thai8
- hp-turkish8
- hz-gb-2312
- ibm037
- ibm038
- ibm1004
- ibm1026
- ibm1047
- ibm1124
- ibm1129
- ibm1132
- ibm1133
- ibm1160
- ibm1161
- ibm1162
- ibm1163
- ibm1164
- ibm256
- ibm273
- ibm274
- ibm275
- ibm277
- ibm278
- ibm280
- ibm281
- ibm284
- ibm285
- ibm290
- ibm297
- ibm420
- ibm423
- ibm424
- ibm437
- ibm500
- ibm850
- ibm851
- ibm852
- ibm855
- ibm856
- ibm857
- ibm858
- ibm860
- ibm861
- ibm862
- ibm863
- ibm864
- ibm865
- ibm866
- ibm866nav
- ibm868
- ibm869
- ibm870
- ibm871
- ibm874
- ibm875
- ibm880
- ibm891
- ibm903
- ibm904
- ibm905
- ibm918
- ibm922
- iec_p27-1
- inis
- inis-8
- inis-cyrillic
- invariant
- isiri-3342
- iso-8859-1
- iso-8859-10
- iso-8859-11
- iso-8859-13
- iso-8859-14
- iso-8859-15
- iso-8859-16
- iso-8859-2
- iso-8859-3
- iso-8859-4
- iso-8859-5
- iso-8859-6
- iso-8859-7
- iso-8859-8
- iso-8859-9
- iso-8859-9e
- iso-ir-197
- iso-ir-209
- iso-ir-90
- iso_10367-box
- iso_10646
- iso_11548-1
- iso_2033-1983
- iso_5427
- iso_5427-ext
- iso_5428
- iso_646.basic
- iso_646.irv
- iso_6937
- iso_6937-2-25
- iso_6937-2-add
- iso_8859-1,gl
- iso_8859-supp
- it
- jis_c6220-1969-jp
- jis_c6220-1969-ro
- jis_c6229-1984-a
- jis_c6229-1984-b
- jis_c6229-1984-b-add
- jis_c6229-1984-hand
- jis_c6229-1984-hand-add
- jis_c6229-1984-kana
- jis_x0201
- johab
- jus_i.b1.002
- jus_i.b1.003-mac
- jus_i.b1.003-serb
- koi-8
- koi8-r
- koi8-ru
- koi8-t
- koi8-u
- ks_c_5601-1987
- ksc5636
- latin-greek
- latin-greek-1
- mac-centraleurope
- mac-cyrillic
- mac-is
- mac-sami
- mac-uk
- macintosh
- mik
- msz_7795.3
- nats-dano
- nats-dano-add
- nats-sefi
- nats-sefi-add
- nc_nc00-10
- nextstep
- nf_z_62-010
- nf_z_62-010_1973
- ns_4551-1
- ns_4551-2
- pt
- pt154
- pt2
- rk1048
- sami
- sami-ws2
- sen_850200_b
- sen_850200_c
- shift_jis
- shift_jisx0213
- t.101-g2
- t.61-7bit
- t.61-8bit
- tcvn5712-1
- tis-620
- tscii
- us-ascii
- utf-7
- utf-8
- videotex-suppl
- viscii
- windows-1251
- windows-1252
- windows-31j- 

some seem incompatible, as file will not load, others load the file but keeps giving the same error...

and I am not finding the Unix file codification that should solve the issue

what codification could I use?

some (on askubuntu, before post got closed) recommend using dos2unix, that will be great if I could have some more access to the system, console, could install packages ... etc..

it is anything I can do to scripting trough cPanel??

---

update 01:

I try with:

export SHELLOPTS
set -o igncr

as https://superuser.com/questions/330781/trouble-editing-bash-profile-bash-r-command-not-found/330783 suggest,

then I got:

./_private/myScript.sh: line 2: export: `SHELLOPTS ': not a valid identifier
./_private/myScript.sh: line 3: set: igncr : invalid option name

---

update 02:

I read somewhere (sorry do not remember post) about -o igncr

so I ask (beg) to program the crons like: (nice -n19 comes as "default", inevitable)

nice -n19 bash -x -o igncr ./_private/myScript.sh
bash -x -o igncr nice -n19 ./_private/myScript.sh

both cases: bash: line 0: bash: igncr: invalid option name

---

I am guessing, start the script with a conditional

sed -i'.bak' s/\r//g ~/myScript.sh

if \r are found in the script??

(inspired on https://stackoverflow.com/questions/11616835/r-command-not-found-bashrc-bash-profile)

Answer 1

I only read the first few lines (too long). But the \r indicates that you are editing on an MS-Windows machine. MS-Windows does line endings in an incompatible way (\r\n). Other systems do (\n).

Solutions:

• Don't use MS-Windows
• Use an editor that can be configured to use the correct line-endings.
• Put the file through dos2unix when importing.

Answer 2

The line ending problem isn't directly related to the character set, e.g. "code page 1252" used by Windows has the carriage return (CR) and line feed (LF) characters, the same as UTF-8. _{(And, since EBCDIC was mentioned, it also seems to have both, plus another newline symbol.What weirdness systems with it actually use is another thing entirely.)}

So, you'd need to find another setting to make the editor create Unix-style line endings, with just the line feed / newline character. Though, you also mention FTP'ing a file to the system, and if that's possible, there shouldn't be anything stopping you to transfer correctly written files that way.

Now, you didn't show what script gave you that "unexpected end of file" error, but it usuallys happen if the shell is expecting a closing quote, or some keyword that has to appear to complete a compound command. Those would be such as then and fi for if; do and done in loops, etc. If the shell sees then\r instead, it doesn't recognize it as a keyword.

However, the trick with commenting out the CR should still work. Bash reads something like this fine, even with CR+LF line endings:

if true; then #
    echo moi  #
fi            #

The hashbang line is more of a problem, though. I can't come up with a way to ignore a CR there, especially with Linux stacking everything after the interpreter name to one argument. But if you already get an error from the shell, you probably are getting the script executed by a shell, at least some shell.