2

It happens when I want to compile some Linux kernel that somehow I end up with such messages:

.../kernel-source/scripts/mkmakefile: line 5: $'\r': command not found

That is because the file is with DOS-EOL instead of the normal one. I usually am able to patch those problematic files with a dos2unix, but in that case, the mkmakefile file is generated by some other script (using Yocto Linux Framework, but I had the same problem with Android build process).

I know there is a igncr bash option for CygWin, but nothing on Linux bash.

Is there a way/option to tell bash to just ignore \r characters (i.e. have \r\n equivalent to \n)?

EDIT: The errors appear on the first blank lines between the shebang and the first executable line (blank lines between comments).

The Yocto logs (which is actually Petalinux, Xilinx' Yocto-based framework) shows:

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: Executing python function check_oldest_kernel
DEBUG: Python function check_oldest_kernel finished
DEBUG: Executing shell function do_configure
NOTE: make HOSTCC=gcc  HOSTCPP=gcc  -E -C .../project/build/tmp/work-shared/plnx_arm/kernel-source O=.../project/build/tmp/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.4+gitAUTOINC+b450e900fd-r0/linux-plnx_arm-standard-build oldnoconfig
NOTE: make HOSTCC=gcc  HOSTCPP=gcc  -E -C .../project/build/tmp/work-shared/plnx_arm/kernel-source O=.../project/build/tmp/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.4+gitAUTOINC+b450e900fd-r0/linux-plnx_arm-standard-build oldconfig
ERROR: oe_runmake failed
make: Entering directory '.../project/build/tmp/work-shared/plnx_arm/kernel-source'
make[1]: Entering directory '.../project/build/tmp/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.4+gitAUTOINC+b450e900fd-r0/linux-plnx_arm-standard-build'
.../project/build/tmp/work-shared/plnx_arm/kernel-source/scripts/mkmakefile: line 5: $'\r': command not found
.../project/build/tmp/work-shared/plnx_arm/kernel-source/scripts/mkmakefile: line 11: $'\r': command not found
.../project/build/tmp/work-shared/plnx_arm/kernel-source/scripts/mkmakefile: line 12: $'\r': command not found
.../project/build/tmp/work-shared/plnx_arm/kernel-source/scripts/mkmakefile: line 52: warning: here-document at line 24 delimited by end-of-file (wanted `EOF')
.../project/build/tmp/work-shared/plnx_arm/kernel-source/scripts/mkmakefile: line 53: syntax error: unexpected end of file
make[1]: *** [.../project/build/tmp/work-shared/plnx_arm/kernel-source/Makefile:461: outputmakefile] Error 2
make[1]: Leaving directory '.../project/build/tmp/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.4+gitAUTOINC+b450e900fd-r0/linux-plnx_arm-standard-build'
make: *** [Makefile:150: sub-make] Error 2

Line 53 is a single EOF marker, without any newline (from cat << EOF > Makefile)

I guess the last line in the generated script is EOF^M, which does not match the expected EOF (without the \r/^M).

closed as unclear what you're asking by Alexander, Isaac, Kiwy, Archemar, Christopher Apr 11 '18 at 14:06

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Where does the files with just \r come from? Yocto should not generate files with \r or ` \r\n` instead of \n, if it does, there is something wrong with Yocto. – Alexander Apr 10 '18 at 12:06
  • @Alexander I edited with the logs. It seems the \r is not the root problem, as I originally suspected. Which is not too helpful for me though... – Matthieu Apr 10 '18 at 12:17
  • 1
    You could probably patch Bash to drop any carriage returns on input though. If cygwin has that feature, they are likely to have a code snippet you could borrow. – ilkkachu Apr 10 '18 at 13:19
1

No, there is no way/option to tell bash to just ignore \r characters (i.e. have \r\n equivalent to \n).

Files can be stored in the file system with either file ending, and bash has no issue with this.

  • Thanks, I did run some tests and it seems bash indeed doesn't care much. The source of my problem is probably somewhere else... – Matthieu Apr 10 '18 at 12:26
  • 2
    Yocto can be pretty opaque and secretive about where the errors really lie, if it's any comfort. – Alexander Apr 10 '18 at 12:29
  • bash has no issue with this but still, when I run unix2dos working.sh, it stops working with /bin/bash^M: bad interpreter... But the rest of the file can have \r\n without any warning, except on blank lines (the script shows the $'\r': command not found but proceeds with the rest of the script). – Matthieu Apr 10 '18 at 17:20
  • It seems the root cause was autocrlf in git, that might have been used somewhere in Petalinux/Yocto. git config --global core.autocrlf input solved it, as stated in my answer below. However, your answer remains correct to my original question "Can we make bash eol tolerant"; it's just my question that was wrong :) – Matthieu Apr 11 '18 at 8:04
1

The root of the problem seems to be caused by git being used internally by the build process. Under Linux, make sure to set the autocrlf to input:

git config --global core.autocrlf input

The build worked fine after that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.