Re: error message lacks useful debugging information
On Fri, 6 Oct 2023 at 01:20, Ángel wrote: > On 2023-10-04 at 20:05 -0400, Dave Cigna wrote: > > Here's how I encountered the problem. You might not be able to > > reproduce > > it on your machine, but that doesn't mean that it's not a bug with > > bash: > > > > download: candle_1.1.7.tar.gz > > from: https://github.com/Denvi/Candle > > Extract to the folder of your choosing. cd to that folder and execute > > the > > bash command: > > > > ../Candle > > For the record, the above program is a 32-bit ELF executable. The most > likely caue for the error in this case is not having the /lib/ld- > linux.so.2 interpreter it requests. Offtopic, but in case it helps Dave Cigna, I have successfully built and run Candle on a 64bit Debian 11 by doing something like: somedir=/where/you/want/candle cd $somedir git clone https://github.com/Denvi/Candle cd $somedir/Candle CMAKE_INSTALL_PREFIX=$somedir/Candle/install cmake src make It might be necessary to install additional required development packages, in my case this included: qtbase5-dev libqt5opengl5-dev libqt5serialport5-dev
"here document" causing failures. Implementation is inconsistent and not documented.
Bug: Trailing white space after the delimiting tag cause the here document to fail with an error like /./: line : warning: here-document at line delimited by end-of-file (wanted `msg_end')Trailing white space/ Trailing white space after the start of the here statement is ignored. This doesn't appear to be documented anywhere. All the material I have seen on here documents I've seen so far never mention the requirement that the tag a the end must be free of any trailing white space. _Inconsistency _: If white space after the start of the here statement is permitted and ignored then it should be the same with a tag terminating the here statement. Test script ___ #/usr/bin/bash cat << msg_end Bash version $(bash --version) msg_end ___ > *# This fails* *> cat -A test_here* #/usr/bin/bash$ cat << msg_end $ $ Bash version$ $(bash --version)$ $ msg_end $ > > *# This works* *> cat -A test_here* #/usr/bin/bash$ cat << msg_end $ $ Bash version$ $(bash --version)$ $ msg_end$ > _ Tested on these, all virtual machines excdept MSYS2 which runs alongside MS Win10. MS WSL2 is a virtual machine. Output is from bash --version and uname -a commands. Zorin Linux - GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) Linux 5.15.0-78-generic #85~20.04.1-Ubuntu SMP Mon Jul 17 09:42:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux MS Windows WSL2 (Ubuntu) GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux MS Windows MSYS2 (derived from Cygwin) GNU bash, version 5.2.15(1)-release (x86_64-pc-msys) MSYS_NT-10.0-19045 bob 3.4.6.x86_64 2023-02-15 18:03 UTC x86_64 Msys Oracle on ARM GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu) Linux ub01 5.15.0-1034-oracle #40-Ubuntu SMP Wed Apr 19 16:10:04 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Re: "here document" causing failures. Implementation is inconsistent and not documented.
On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > Bug: > Trailing white space after the delimiting tag cause the here document to > fail with an error like > /./: line : warning: here-document at line > delimited by end-of-file (wanted `msg_end')Trailing white > space/ > > Trailing white space after the start of the here statement is ignored. To be fair, whitespace *is* possible within the delimiting word, if the word is quoted. unicorn:~$ ebase -host localhost unicorn:~$ cat <<'EOF ' > EOF > EOF EOF In the example above, there are two spaces on the second line which starts with '> EOF'. The first line has no trailing whitespace, so it doesn't match the delimiting word. The second line has the two trailing spaces, so it matches. The shell is acting correctly here; if you feel the documentation could be improved, that's fair. But it seems fairly clear to me: Here Documents This type of redirection instructs the shell to read input from the current source until a line containing only delimiter (with no trailing blanks) is seen.
Re: "here document" causing failures. Implementation is inconsistent and not documented.
On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > Bug: > Trailing white space after the delimiting tag cause the here document to > fail with an error like > /./: line : warning: here-document at line > delimited by end-of-file (wanted `msg_end')Trailing white > space/ > > Trailing white space after the start of the here statement is ignored. > > This doesn't appear to be documented anywhere. All the material I have seen > on here documents I've seen so far never mention the requirement that the > tag a the end must be free of any trailing white space. > > _Inconsistency _: If white space after the start of the here statement is > permitted and ignored then it should be the same with a tag terminating the > here statement. > > Test script > ___ > #/usr/bin/bash > cat << msg_end Here, "msg_end" is a word in the shell script. It is not initiating the here-document *at that instance*. The here-document starts on the next line. The here-document is terminated by the occurence of the "msg_end" word on a line by itself. Consider also cat << msg_end | mailx -s "Test" u...@example.com my message goes here msg_end This would be impossible if the shell interpreted the first instance of "msg_end" as anything other than an ordinary word in the script. I'm using the word "word" loosely here. I'm not a grammar expert, but I might mean "token". > > Bash version > $(bash --version) > > msg_end > ___ > > *# This fails* > *> cat -A test_here* > #/usr/bin/bash$ > cat << msg_end $ > $ > Bash version$ > $(bash --version)$ > $ > msg_end $ > > > > *# This works* > *> cat -A test_here* > #/usr/bin/bash$ > cat << msg_end $ > $ > Bash version$ > $(bash --version)$ > $ > msg_end$ > > > _ > Tested on these, all virtual machines excdept MSYS2 which runs alongside MS > Win10. MS WSL2 is a virtual machine. > Output is from bash --version and uname -a commands. > > Zorin Linux - > GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) > Linux 5.15.0-78-generic #85~20.04.1-Ubuntu SMP Mon Jul 17 09:42:39 UTC > 2023 x86_64 x86_64 x86_64 GNU/Linux > > MS Windows WSL2 (Ubuntu) > GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) > Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC > 2023 x86_64 x86_64 x86_64 GNU/Linux > > MS Windows MSYS2 (derived from Cygwin) > GNU bash, version 5.2.15(1)-release (x86_64-pc-msys) > MSYS_NT-10.0-19045 bob 3.4.6.x86_64 2023-02-15 18:03 UTC x86_64 Msys > > Oracle on ARM > GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu) > Linux ub01 5.15.0-1034-oracle #40-Ubuntu SMP Wed Apr 19 16:10:04 UTC 2023 > aarch64 aarch64 aarch64 GNU/Linux -- Andreas (Kusalananda) Kähäri Uppsala, Sweden .
