Summary: | bashisms in several scripts | ||
---|---|---|---|
Product: | [Developer tools] kdesdk-scripts | Reporter: | Peter Eisentraut <peter_e> |
Component: | Miscellaneous | Assignee: | Michael Pyne <mpyne> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Patch to fix all bashisms |
Description
Peter Eisentraut
2008-04-04 16:42:24 UTC
Created attachment 24185 [details]
Patch to fix all bashisms
SVN commit 808191 by mpyne: Make some kdesdk scripts either POSIX sh compliant, or notate them as requiring bash in KDE trunk. CCBUG:160368 M +1 -1 adddebug M +1 -1 create_svnignore M +1 -1 svnaddcurrentdir WebSVN link: http://websvn.kde.org/?view=rev&revision=808191 SVN commit 808193 by mpyne: Make some kdesdk scripts either POSIX sh compliant or ensure that they use bash in KDE 4.0 branch. Patch from Peter Eisentraut (I use printf instead of echo because echo is apparently fairly divergent in its effects in sh implementation, printf is much better defined). BUG:160368 M +1 -1 adddebug M +1 -1 create_svnignore M +1 -1 svnaddcurrentdir WebSVN link: http://websvn.kde.org/?view=rev&revision=808193 Replacing echo with plain printf isn't POSIX compliant according to my local POSIX fprint man page: -- The argument operands shall be treated as strings if the corresponding conversion specifier is b, c, or s ; otherwise, it shall be evaluated as a C constant, as described by the ISO C standard [... -- so "printf %s" is what you want. Unless I've split the format string into two or more somewhere it should be POSIX compliant. The "argument operands" are talking about the arguments passed to printf in addition to the format string. In this case I've only passed the format string which according to all the man pages I've checked is just fine. I don't have your manpage however so if you could link me to it I'll take a closer look. > Unless I've split the format string into two or more somewhere it should be POSIX compliant. The standard speaks otherwise. > I don't have your manpage [... It's the same information you can find here: http://www.opengroup.org/onlinepubs/009695399/ printf, extended information,right after the exception list Cannot be more official, can it?! ;) Carsten, according to the POSIX documentation you've provided the format string is correct in all cases (printf documentation from http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html). You are correct in that printf "string" is not a general replacement for echo. POSIX requires (http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html#tag_04_41_16) printf to be used with either "%s" or "%b" (for BSD and SysV echo) to be a drop-in replacement for echo. But I don't need a drop-in replacement, I just need something to evaluate \n. The printf documentation includes an example that does exactly that: "To alert the user and then print and read a series of prompts: printf "\aPlease fill in the following: \nName: " read name printf "Phone number: " read phone " Notice that no %s was used. It is not required because the format operand (the first parameter passed to printf): "...shall be used as the format string described in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 5, File Format Notation with the following exceptions: *snip*" You can read the Chap 5 description here: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap05.html Of note is that 1. /Characters/ that are not escapes or conversion specifiers are copied to stdout, and that '\n' newline is a valid escape character (which is what I'm using printf for). Thanks for taking the time and sorry for the noise. I stand corrected. |