My gentoo /bin/sh (which is bash) unlike dash generates a broken whitespace.h file from the current bin/getwhitespace.sh . I dont know which of the two is wrong here, but should we simply use numeric values instead of character escapes?
arne
On Wed, Feb 26, 2014 at 3:47 AM, Arne Goedeke el@laramies.com wrote:
My gentoo /bin/sh (which is bash) unlike dash generates a broken whitespace.h file from the current bin/getwhitespace.sh . I dont know which of the two is wrong here, but should we simply use numeric values instead of character escapes?
arne
There's a difference between bash and dash handling there. I suspect the easiest solution will be to switch to a heredoc, which - not being a quoted string itself - doesn't parse apostrophes. It's not as tidy as the other version, though.
Patch attached.
ChrisA
I wasnt sure whats a portable fix. Interestingly, any backslash in an argument to echo is undefined behavior, according to posix, so I suppose echo ought to be avoided in this case.
arne
On Wed, 26 Feb 2014, Chris Angelico wrote:
On Wed, Feb 26, 2014 at 3:47 AM, Arne Goedeke el@laramies.com wrote:
My gentoo /bin/sh (which is bash) unlike dash generates a broken whitespace.h file from the current bin/getwhitespace.sh . I dont know which of the two is wrong here, but should we simply use numeric values instead of character escapes?
arne
There's a difference between bash and dash handling there. I suspect the easiest solution will be to switch to a heredoc, which - not being a quoted string itself - doesn't parse apostrophes. It's not as tidy as the other version, though.
Patch attached.
ChrisA
On Wed, Feb 26, 2014 at 5:08 AM, Arne Goedeke el@laramies.com wrote:
I wasnt sure whats a portable fix. Interestingly, any backslash in an argument to echo is undefined behavior, according to posix, so I suppose echo ought to be avoided in this case.
I'm not 100% sure about the portability of single-quoted heredoc syntax, so that might need to be checked.
BTW, need to strip off a pile of those backslashes. Alternative patch attached.
ChrisA
Simply replacing echo by printf also works and _should_ be portable. At least posix does not say anything about 'implementation defined'.
arne
On Wed, 26 Feb 2014, Chris Angelico wrote:
On Wed, Feb 26, 2014 at 5:08 AM, Arne Goedeke el@laramies.com wrote:
I wasnt sure whats a portable fix. Interestingly, any backslash in an argument to echo is undefined behavior, according to posix, so I suppose echo ought to be avoided in this case.
I'm not 100% sure about the portability of single-quoted heredoc syntax, so that might need to be checked.
BTW, need to strip off a pile of those backslashes. Alternative patch attached.
ChrisA
On Wed, Feb 26, 2014 at 5:20 AM, Arne Goedeke el@laramies.com wrote:
Simply replacing echo by printf also works and _should_ be portable. At least posix does not say anything about 'implementation defined'.
Ah, good. Always take the simplest available solution :)
ChrisA
The only problem with printf is that it seems to be missing on my embedded ARM fan controller. Not really important, though, I guess, since it is also missing a working linker currently. :)
I believe using a here-document would be more portable. I've used several UNIX(tm) systems that have lacked printf(1).
Chris Angelico wrote:
I'm not 100% sure about the portability of single-quoted heredoc syntax, so that might need to be checked.
+cat <<'EOM'
What I've always used (since the dawn of time), is cat <<\EOM Which is perfectly portable, backward and forward from 1985 to 2014 and back.
On Wed, Feb 26, 2014 at 1:00 PM, Stephen R. van den Berg srb@cuci.nl wrote:
Chris Angelico wrote:
I'm not 100% sure about the portability of single-quoted heredoc syntax, so that might need to be checked.
+cat <<'EOM'
What I've always used (since the dawn of time), is cat <<\EOM Which is perfectly portable, backward and forward from 1985 to 2014 and back.
Yes, that version is portable, but it's slightly different. Putting the end marker in single quotes makes the entire string unparsed, same as a single-quoted string would otherwise be.
ChrisA
Chris Angelico wrote:
+cat <<'EOM'
What I've always used (since the dawn of time), is cat <<\EOM Which is perfectly portable, backward and forward from 1985 to 2014 and back.
Yes, that version is portable, but it's slightly different. Putting the end marker in single quotes makes the entire string unparsed, same as a single-quoted string would otherwise be.
I'd beg to differ. <<'EOM' and <<\EOM should be identical in behaviour. AFAIK *any* kind of quoting of the marker behind << will result in the behaviour you describe.
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Chris Angelico -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Per Hedbor () ＠ Pike (-) developers forum
-
Stephen R. van den Berg