Version: (using Devel) Installed from: Compiled sources Several scripts in kdesdk-scripts contain bashisms. Some Linux distributions (such as Debian and Ubuntu) are now moving away from bash as /bin/sh, so either these scripts should be restricted to using POSIX and other portable features, or they should explicitly call bash instead of /bin/sh. The attached patch fixes all the known issues.
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.