mirror of
https://git.busybox.net/buildroot.git
synced 2024-11-24 05:53:30 +08:00
ac2e6b3927
Lots of people are using broken text editors that 1. do not naturally terminate text files with a final \n as is customary in UNIX text files, and 2. do not respect our .editorconfig settings, which explicitly require adding that final newline. See this nice summary of what a text file is (with references to applicable standards): https://stackoverflow.com/questions/12916352/shell-script-read-missing-last-line/12916758#12916758 So, it is not surprising that read does not read the last "line" of a file, when said "line" does not end with a newline, because it is thus not really a line. Even though we do mandate actual text files, let's be a little bit lax in this respect, because people may write packages, and their hash files, in a br2-external tree, and they may not have our .editorconfig in the directory heierarchy (e.g. if buildroot is a submodule of their br2-external tree, or whatever). mapfile does not suffer from this limitation, though, and correctly reads all lines from a file, even the final line-that-is-not-a-line. mapfile was introduced in bash 4.0, released on 2009-01-20, more than 15 years ago. Debian squeeze, released in 2011 already had bash 4.1. Those are really ancient. So, it means we can indeed expect bash version 4.0 or later; which means mapfile is available. "It should be fine!" Fixes: #15976 Reported-by: masonwardle@gmail.com Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle <arnout@mind.be> |
||
---|---|---|
.. | ||
bzr | ||
cargo-post-process | ||
check-hash | ||
curl | ||
cvs | ||
dl-wrapper | ||
file | ||
git | ||
go-post-process | ||
helpers | ||
hg | ||
scp | ||
sftp | ||
svn | ||
wget |