Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Hi, On 8 July 2012 19:22, Jonathan Nieder jrnie...@gmail.com wrote: In July, 2008, Raphael Geissert wrote: As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. [...] Shells tested: 8 Shells expandind backslashes: 5 /bin/echo does NOT expand [...] I think it would make sense to discourage use of strings that might contain a backslash as arguments to echo in some informative document such as devref or in a footnote to policy. And the use of strings that might begin with a dash character (minus sign, actually), as demonstrated by the incompatible behaviour with strings such as -e, -E, --, --version, --help. The discussion of this bug seems to have clarified that use of echo and echo -n to print static strings is popular and not something that is going away soon. I would prefer to back those statements up with real figures, but let's assume for a moment that the opinion of those who have commented on the report reflect reality. Does that seem like a fair summary? What do you suggest as a next step? I think that proposing a wording based on the above is the next step forward. Policy editors: do you have any suggestion as to where such informative notes should be added? perhaps as another footnote to section 10.4, referenced by echo -n exception? Additionally, I think that the echo -n exception should better be phrased in the following way: 'echo', if implemented as a shell built-in, must not generate a newline when the first operand is '-n'. Rationale: consistency with the other exceptions, where the name of the utilities are first mentioned without any arguments. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Hi, In July, 2008, Raphael Geissert wrote: As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. [...] + o='Foo:\n\tI do not like bar!!\n\nBar:\n\tI do not like you either' [...] Shells tested: 8 Shells expandind backslashes: 5 /bin/echo does NOT expand 8---trivia-ends-here---8 Additionally, the usage of echo -n should also be discouraged because it may not help stressing the idea of echo not being portable. I think it would make sense to discourage use of strings that might contain a backslash as arguments to echo in some informative document such as devref or in a footnote to policy. The discussion of this bug seems to have clarified that use of echo and echo -n to print static strings is popular and not something that is going away soon. Does that seem like a fair summary? What do you suggest as a next step? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, Jun 04, 2009 at 10:16:06PM +0100, Adam D. Barratt wrote: So printf is slightly unwiedly to use and it can create format string attack. It does, however, have the advantage of working if BAR contains -E. (This isn't a contrived example, it's why I recently changed the parsing of DEBUILD_LINTIAN_OPTS to use printf rather than echo; if there's a sane way of printing -E using echo I'd love to know what it is). Not quite correct, but echo -E does print -E Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Geissert wrote: On Tuesday 02 June 2009 12:54:00 Bill Allombert wrote: [...] It does not make sense to policy to discourage echo -n. Policy could deprecate it in favor of something else, but I do not see any alternative mentioned in this bug report, and otherwise discouraging echo -n would amount to discourage shell scripts to display lines that does not end by a newline, while Policy 9.4. mandates that init scripts display Starting foo without an ending newline. Furthermore, adding vague recommendation to policy is a waste of resource. So, is there an alternative to echo -n that you would like to recommends, and are you willing to do the job to make sure that all Debian sh-compliant shells in Debian support it ? I think we could forbid echo -n on maintainer and other scripts, but allow it on init.d scripts. Rationale: - portability is more important on other scripts, and it is also not so frequent to use echo -n - init.d are system scripts which special requirement, so they are not portable. And we could ev. workaround with a special alias/path which set a non-portable echo. This is also simple because init.d scripts sould be called only by/via few programs/ Yes, printf. It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Most of people understand echo -n, but I don't know if all people understand fully printf. Mixing echo and printf is ugly. Anyway the standard are helper tools, not tools to make difficult the live of user and maintainer. See for example the recent discussion about ext3, see the old discussion about tar (tar is not in POSIX, people should use 'pax') BTW I think this is incorrect: $ POSIXLY_CORRECT=1 bash -c echo -n line one; echo line two; line oneline two ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, 04 Jun 2009, Giacomo Catenazzi wrote: It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Ugliness is relative. I have no problem with printf. For the second argument: [ using bash ] $ type printf printf is a shell builtin $ dash $ type printf printf is a shell builtin There's no external executable needed. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, Jun 4, 2009 at 11:53:19 +0200, Raphael Hertzog wrote: On Thu, 04 Jun 2009, Giacomo Catenazzi wrote: It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Ugliness is relative. I have no problem with printf. While I have no problem with printf, I also think mixing printf and echo is ugly, and I'm not at all convinced by the arguments to discourage echo -n or echo in general. I also think making different recommendations based on type of script (init scripts vs maintainer scripts vs whatever else) is a very, very bad idea. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Hertzog wrote: For the second argument: [ using bash ] $ type printf printf is a shell builtin $ dash $ type printf printf is a shell builtin There's no external executable needed. but also echo -n is recognized by these tools. I've interpreted the original bug report as a way to allow any conform shell to be used. OTOH it could be seen differently: as a way to educate user to write conform scripts, and to simplify the reading of script by non debian or non linux user. [But I'm pretty sure that we will fail this last point: IMHO it would port to lsb or other utilities similar to debhelper, thus still requiring some insight into Linux specific features] ciao cate PS: Anyway, it would be simple to move printf to /bin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, Jun 04, 2009 at 11:53:19AM +0200, Raphael Hertzog wrote: On Thu, 04 Jun 2009, Giacomo Catenazzi wrote: It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Ugliness is relative. I have no problem with printf. Consider this example: the safe printf way to do echo $BAR is printf %s\n $BAR (in case BAR hold a value like BAR=%s a) So printf is slightly unwiedly to use and it can create format string attack. For the second argument: [ using bash ] $ type printf printf is a shell builtin $ dash $ type printf printf is a shell builtin There's no external executable needed. Are all these shell builtin compatible with /usr/bin/printf ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thursday 04 June 2009 01:28:01 Giacomo Catenazzi wrote: Raphael Geissert wrote: I think we could forbid echo -n on maintainer and other scripts, but allow it on init.d scripts. Like Julien said, I think making different recommendations is a bad idea. Rationale: - portability is more important on other scripts, and it is also not so frequent to use echo -n No, not really. In a large project the interest is to be as portable as possible, diverging as less as possible to support different ecosystems. And that applies to all kind of code. Yes, printf. It is not an alternative: - It is ugly You say it is ugly, I say it is pretty, and none of us can be proved right or wrong because it is a subjective statement. Rephrasing or otherwise omitting that statement would be better for the sake of the discussion. - it is not on root partition Only when not implemented as a shell built-in (which is very very rare, and I think of all the shell interpreters in Debian only posh doesn't implement it because it is not required by policy.) However, if it is a real concern then we could request printf to be installed in /bin. Most of people understand echo -n, but I don't know if all people understand fully printf. Mixing echo and printf is ugly. printf exists as-is or has an equivalent in most programming languages, so I doubt a more or less formed programmer won't know how printf works. OTOH, echo -n is just a bashism, not even an XSIsm[1], and the option name doesn't tell much about what it does. Not to mention that this discussion is not only about *discouraging* (not forbidding!) the -n option, but when passing a string with backlashes to echo. Anyway the standard are helper tools, not tools to make difficult the live of user and maintainer. 'echo' is a portability nightmare if not used properly, I don't know how you could say it helps. See for example the recent discussion about ext3, see the old discussion about tar (tar is not in POSIX, people should use 'pax') I think that's irrelevant, and for the sake of this discussion I would like if you could stop giving examples of how we are not POSIX. The reasons for that, I think, are pretty obvious. BTW I think this is incorrect: $ POSIXLY_CORRECT=1 bash -c echo -n line one; echo line two; line oneline two Policy doesn't make any exeption, so the behaviour follows what policy mandates. It is just another example of why we can't rely on echo. [1] On XSI-conformant systems, if the first operand is -n, it shall be treated as a string, not an option. Regards, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thursday 04 June 2009 07:14:25 Bill Allombert wrote: On Thu, Jun 04, 2009 at 11:53:19AM +0200, Raphael Hertzog wrote: [...] Ugliness is relative. I have no problem with printf. Consider this example: the safe printf way to do echo $BAR is printf %s\n $BAR (in case BAR hold a value like BAR=%s a) So printf is slightly unwiedly to use and it can create format string attack. If not used properly, just like many other features/tools can lead to some sort of security issue. Adding a note that passing variables as the first argument to printf should only be done when the necessary precautions to avoid string attacks have been taken. Similar to what it says about temporary files. For the second argument: [ using bash ] $ type printf printf is a shell builtin $ dash $ type printf printf is a shell builtin There's no external executable needed. Are all these shell builtin compatible with /usr/bin/printf ? Yes, because printf is well defined. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, 2009-06-04 at 14:14 +0200, Bill Allombert wrote: Consider this example: the safe printf way to do echo $BAR is printf %s\n $BAR (in case BAR hold a value like BAR=%s a) So printf is slightly unwiedly to use and it can create format string attack. It does, however, have the advantage of working if BAR contains -E. (This isn't a contrived example, it's why I recently changed the parsing of DEBUILD_LINTIAN_OPTS to use printf rather than echo; if there's a sane way of printing -E using echo I'd love to know what it is). Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Adam D. Barratt a...@adam-barratt.org.uk writes: On Thu, 2009-06-04 at 14:14 +0200, Bill Allombert wrote: Consider this example: the safe printf way to do echo $BAR is printf %s\n $BAR (in case BAR hold a value like BAR=%s a) So printf is slightly unwiedly to use and it can create format string attack. But at least one can make it save even with user input. echo $BAR can never be safe. It does, however, have the advantage of working if BAR contains -E. (This isn't a contrived example, it's why I recently changed the parsing of DEBUILD_LINTIAN_OPTS to use printf rather than echo; if there's a sane way of printing -E using echo I'd love to know what it is). Regards, Adam bash: $ echo - -E - -E $ echo -- -E -- -E zsh: % echo - -E -E % echo -- -E -- -E So I would have to say echo -- -E | cut -b4-. Isn't that fun. The same problem arises with -e and -n. And --help and --version are fun too. gnu echo has then, others don't. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Mon, Jun 01, 2009 at 01:38:37AM -0500, Raphael Geissert wrote: - -n is so wide used, that other solution will create more bugs! Anyway, no user should use echo -n to print -n (POSIX discurages it), so again, it is a non-problem. The idea is to explicitely discourage its usage, not to forbid it. It does not make sense to policy to discourage echo -n. Policy could deprecate it in favor of something else, but I do not see any alternative mentioned in this bug report, and otherwise discouraging echo -n would amount to discourage shell scripts to display lines that does not end by a newline, while Policy 9.4. mandates that init scripts display Starting foo without an ending newline. Furthermore, adding vague recommendation to policy is a waste of resource. So, is there an alternative to echo -n that you would like to recommends, and are you willing to do the job to make sure that all Debian sh-compliant shells in Debian support it ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Tuesday 02 June 2009 12:54:00 Bill Allombert wrote: [...] It does not make sense to policy to discourage echo -n. Policy could deprecate it in favor of something else, but I do not see any alternative mentioned in this bug report, and otherwise discouraging echo -n would amount to discourage shell scripts to display lines that does not end by a newline, while Policy 9.4. mandates that init scripts display Starting foo without an ending newline. Furthermore, adding vague recommendation to policy is a waste of resource. So, is there an alternative to echo -n that you would like to recommends, and are you willing to do the job to make sure that all Debian sh-compliant shells in Debian support it ? Yes, printf. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Sunday 13 July 2008 04:57:13 Raphael Hertzog wrote: On Sat, 12 Jul 2008, Raphael Geissert wrote: Package: debian-policy Version: 3.0.8.1 Severity: wishlist As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. Well, you just proved that you can't rely on correct interpretation of special escaped characters and that's true. It's not a reason to discourage echo or echo -n in general though. That would be ridiculous given how frequently it's used. Partially acknowledged, as I still would prefer echo -n to be supported but discouraged. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Sunday 13 July 2008 13:38:56 Russ Allbery wrote: I realize that Policy already provides a little bit of generic advice about writing shell scripts, so it's not like we have a particularly pure distinction on which to stand, but unless we're going to require particular practices via filing bugs I think putting best practices in the devref may be better. Discouraging printing strings containing backslashes with echo is not justt best practice, but by not doing so it makes the script prone to portability issues and policy violations (the only escape sequence that appears to work on all shells and is used by libtool is \\). Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Monday 14 July 2008 03:52:34 Giacomo A. Catenazzi wrote: [...] For echo: http://kerneltrap.org/man/linux/man1p/echo.1p OpenGroup version: http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html I don't think this bug need to be address, for the following reasons: - I don't find debian scripts which uses escapes (but one of mine package in stable, on the non-debian support part) If by debian scripts you mean maintainer scripts, I remember seeing some of those; if you mean scripts shipped in/by Debian then there are many of those. A good start point is: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.orgtag=goal-dash Example: http://bugs.debian.org/530041 Eventually policy could state that escapes should not be used in echo. - -n is so wide used, that other solution will create more bugs! Anyway, no user should use echo -n to print -n (POSIX discurages it), so again, it is a non-problem. The idea is to explicitely discourage its usage, not to forbid it. note: it can is very easy corrected by wrapper (or shell alias) - I think the debian script are is outside POSIX scope: - the system is not completely up, so POSIX commands and support is incomplete. Anyway the init.d scripts use usually other non-portable command (i.e. mount), so - the installation of program is also outside POSIX scope: it modify system in a manner not allowed by portable scripts. So, IMHO, there is noway to have debian script compatible 100% to posix. Those arguments are irrelevant, as this is not about being fully POSIX conformant. Even if the script is run inside an initramfs which uses busybox's sh it is mandated by policy, and if it declares it is a /bin/sh script then it must conform to whatever policy dictates it must. Regards, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 12 Jul 2008, Raphael Geissert wrote: As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. Well, you just proved that you can't rely on correct interpretation of special escaped characters and that's true. It's not a reason to discourage echo or echo -n in general though. That would be ridiculous given how frequently it's used. But it would be nice to remember that printf must be used if you want to reliably use escaped characters. But here you must take care to use %s for each variable expansion: echo a $var\n b is printf a %s\n b\n $var I realize that Policy already provides a little bit of generic advice about writing shell scripts, so it's not like we have a particularly pure distinction on which to stand, but unless we're going to require particular practices via filing bugs I think putting best practices in the devref may be better. Policy does say by reference that echo varies. It referes to SUS, which says: If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined. and: It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted. The printf utility can be used portably to emulate any of the traditional behaviors of the echo utility as follows (assuming that IFS has its standard value or is unset): [...] We of course override the part about -n and require that it behave in a particular way, but the part about backslashes remains. It's unfortunate that SUS requires free registration; it makes it harder to link directly to specific sections of interest. The POSIX pages are available online, in http://kerneltrap.org/man/linux unfortunately they are not very well formatted (some extra groff are written on html) For echo: http://kerneltrap.org/man/linux/man1p/echo.1p I don't think this bug need to be address, for the following reasons: - I don't find debian scripts which uses escapes (but one of mine package in stable, on the non-debian support part) Eventually policy could state that escapes should not be used in echo. - -n is so wide used, that other solution will create more bugs! Anyway, no user should use echo -n to print -n (POSIX discurages it), so again, it is a non-problem. note: it can is very easy corrected by wrapper (or shell alias) - I think the debian script are is outside POSIX scope: - the system is not completely up, so POSIX commands and support is incomplete. Anyway the init.d scripts use usually other non-portable command (i.e. mount), so - the installation of program is also outside POSIX scope: it modify system in a manner not allowed by portable scripts. So, IMHO, there is noway to have debian script compatible 100% to posix. So I would reject the bug, until we don't see real problems. OTOH moving to LSB command could help in this case, help logging and give some colors to users. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Sat, 12 Jul 2008, Raphael Geissert wrote: Package: debian-policy Version: 3.0.8.1 Severity: wishlist As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. Well, you just proved that you can't rely on correct interpretation of special escaped characters and that's true. It's not a reason to discourage echo or echo -n in general though. That would be ridiculous given how frequently it's used. But it would be nice to remember that printf must be used if you want to reliably use escaped characters. But here you must take care to use %s for each variable expansion: echo a $var\n b is printf a %s\n b\n $var Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 12 Jul 2008, Raphael Geissert wrote: As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. Well, you just proved that you can't rely on correct interpretation of special escaped characters and that's true. It's not a reason to discourage echo or echo -n in general though. That would be ridiculous given how frequently it's used. But it would be nice to remember that printf must be used if you want to reliably use escaped characters. But here you must take care to use %s for each variable expansion: echo a $var\n b is printf a %s\n b\n $var I realize that Policy already provides a little bit of generic advice about writing shell scripts, so it's not like we have a particularly pure distinction on which to stand, but unless we're going to require particular practices via filing bugs I think putting best practices in the devref may be better. Policy does say by reference that echo varies. It referes to SUS, which says: If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined. and: It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted. The printf utility can be used portably to emulate any of the traditional behaviors of the echo utility as follows (assuming that IFS has its standard value or is unset): [...] We of course override the part about -n and require that it behave in a particular way, but the part about backslashes remains. It's unfortunate that SUS requires free registration; it makes it harder to link directly to specific sections of interest. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Package: debian-policy Version: 3.0.8.1 Severity: wishlist As demonstrated by the following trivia[1], and also mentioned by SUSv3, the echo built-in varies from implementation to implementation and thus should be discouraged. 8---trivia-starts-here---8 $ ./echo-trivia.sh ++ bash + o='Foo:\n\tI do not like bar!!\n\nBar:\n\tI do not like you either' + set +x ++ dash + o='Foo: I do not like bar!! Bar: I do not like you either' + set +x ++ ksh + o='Foo:\n\tI do not like bar!!\n\nBar:\n\tI do not like you either' + set +x ++ zsh + o='Foo: I do not like bar!! Bar: I do not like you either' + set +x ++ posh + o='Foo: I do not like bar!! Bar: I do not like you either' + set +x ++ pdksh + o='Foo: I do not like bar!! Bar: I do not like you either' + set +x ++ mksh + o='Foo: I do not like bar!! Bar: I do not like you either' + set +x ++ busybox sh + o='Foo:\n\tI do not like bar!!\n\nBar:\n\tI do not like you either' + set +x ==Trivia results== Shells tested: 8 Shells expandind backslashes: 5 /bin/echo does NOT expand 8---trivia-ends-here---8 Additionally, the usage of echo -n should also be discouraged because it may not help stressing the idea of echo not being portable. Finally, completely OT but I don't believe it warrants yet another bug report, the following line should also mention the [ built-in and not just test: test, if implemented as a shell built-in, must support -a and -o as binary logical operators. [1] The script basically prints some text with 'echo' which containing backslashes and checks whether the backslashes were expanded or not. Kind regards, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html signature.asc Description: This is a digitally signed message part.
