Re: echo -n
2017-02-06 09:45:26 +0530, Jyoti B Tenginakai: [...] > Again I see that this printf we can use. But there are some scenarios where > the o/p does not exactly match with echo. So still its good to have a way > to pirnt -n /-e/-E with echo. Can this be considered as bug and can this be > fixed? [...] echo -e '\055n' # on ASCII-based systems echo -e '-n\n\c' echo -ne '-n\n' Output "-n" with bash's echo and with the default options. When in Unix conformance mode (shopt -s xpg_echo; set -o posix) echo -n outputs -n followed by a newline character, while echo '-n\c' outputs it without the newline character. All the functionality of echo is available in printf. The %b format directive has especially been introduced (by POSIX) to cover for the peculiar style of expansion done by echo (note the need for \055 instead of \55 like everywhere else) so we have no excuse to keep using echo. echo_E() { local IFS=' ' printf '%s\n' "$*" } echo_e() { local IFS=' ' printf '%b\n' "$*" } echo_nE() { local IFS=' ' printf %s "$*" } echo_ne() { local IFS=' ' printf %b "$*" } echo is broken. Stop using it. ksh and zsh introduced a "print" builtin that fixes some of echo problems (though it still does expansions by default which you can disable with -r), but bash chose not to implement it, but does implement the POSIX (though less Unixy in its CLI style) printf instead. -- Stephane
Re: echo -n
Depending on your use case, you could do something like: $ echo $'\u2010'n -n On 06/02/2560 13:37, Clark Wang wrote: > On Mon, Feb 6, 2017 at 12:15 PM, Jyoti B Tenginakai > mailto:jyoti@in.ibm.com>> wrote: > > Thanks you all, > > Again I see that this printf we can use. But there are some > scenarios where the o/p does not exactly match with echo. So still > its good to have a way to pirnt -n /-e/-E with echo. Can this be > considered as bug and can this be fixed? > > It’s not a bug. According to POSIX.1-2008: > > The |echo| utility shall not recognize the |"--"| argument in the > manner specified by Guideline 10 of XBD Section 12.2; |"− −"| shall > be recognized as a string operand. > > 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 |echo| utility has not been made obsolescent because of its > extremely widespread use in historical applications. > >
Re: echo -n
On Mon, Feb 6, 2017 at 12:15 PM, Jyoti B Tenginakai wrote: Thanks you all, > > Again I see that this printf we can use. But there are some scenarios > where the o/p does not exactly match with echo. So still its good to have a > way to pirnt -n /-e/-E with echo. Can this be considered as bug and can > this be fixed? > It’s not a bug. According to POSIX.1-2008: The echo utility shall not recognize the "--" argument in the manner specified by Guideline 10 of XBD Section 12.2; "− −" shall be recognized as a string operand. 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 echo utility has not been made obsolescent because of its extremely widespread use in historical applications.
Re: echo -n
Thanks you all, Again I see that this printf we can use. But there are some scenarios where the o/p does not exactly match with echo. So still its good to have a way to pirnt -n /-e/-E with echo. Can this be considered as bug and can this be fixed? Thanks & Regards --Jyoti Jyoti Tenginakai AIX-Security Development Team IBM India Software Lab EGD 'D' Block Sixth Floor Off Indiranagar Koramangala Intermediate Ring Road Bangaluru - 560071 ph: 4177 extn: 7 Mail:jyoti@in.ibm.com From: Chet Ramey To: Jyoti B Tenginakai , Pierre Gaston Cc: chet.ra...@case.edu, Sangamesh Mallayya , "bug-bash@gnu.org" Date: 02/02/2017 11:21 PM Subject:Re: echo -n On 2/2/17 11:56 AM, Jyoti B Tenginakai wrote: > HI All, > > Thanks for your quick response. > > I have tried using the printf instead of echo. But the issue with printf is > , the behaviour is not consistent with what echo prints for all the inputs > i.e. > In my script I am generically using echo for all the options. If I have to > use printf instead of it should behave consistently . > if echo * is passed to bash shell, the o/p shows the \t seperated values > whereas with printf '%s' *, it won't display space separated output. Again > printf '%s ' # behaviour is different from what echo # shows echo() { builtin printf "%s\n" "$*" } You can make this more elaborate if you want. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: echo -n
2017-02-02 22:26:22 +0530, Jyoti B Tenginakai: [...] > I have tried using the printf instead of echo. But the issue with printf > is , the behaviour is not consistent with what echo prints for all the > inputs i.e. > In my script I am generically using echo for all the options. If I have to > use printf instead of it should behave consistently . > if echo * is passed to bash shell, the o/p shows the \t seperated values > whereas with printf '%s' *, it won't display space separated output. Again > printf '%s ' # behaviour is different from what echo # shows [...] See also: https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo In bash, you can define: puts() { local IFS=' ' printf '%s\n' "$*" } as a function that outputs its arguments separated by spaces and terminated with a newline character. POSIXly: puts() ( IFS=' ' printf '%s\n' "$*" ) With with some shells like bash, that implies an additional fork. Note hat ksh and zsh also have: print -r -- * for that. -- Stephane
Re: echo -n
On 2/2/17 11:56 AM, Jyoti B Tenginakai wrote: > HI All, > > Thanks for your quick response. > > I have tried using the printf instead of echo. But the issue with printf is > , the behaviour is not consistent with what echo prints for all the inputs > i.e. > In my script I am generically using echo for all the options. If I have to > use printf instead of it should behave consistently . > if echo * is passed to bash shell, the o/p shows the \t seperated values > whereas with printf '%s' *, it won't display space separated output. Again > printf '%s ' # behaviour is different from what echo # shows echo() { builtin printf "%s\n" "$*" } You can make this more elaborate if you want. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: echo -n
On Thu, Feb 2, 2017 at 10:56 AM, Jyoti B Tenginakai wrote: > HI All, > > Thanks for your quick response. > > I have tried using the printf instead of echo. But the issue with printf > is , the behaviour is not consistent with what echo prints for all the > inputs i.e. > In my script I am generically using echo for all the options. If I have to > use printf instead of it should behave consistently . > if echo * is passed to bash shell, the o/p shows the \t seperated values > whereas with printf '%s' *, it won't display space separated output. Again > printf '%s ' # behaviour is different from what echo # shows > Yes, it is. You can change the output by using the appropriate "format" (the '%s' in your example). For example: echo -n * could be emulated with: printf '%s ' * #note the space in the format after the %s The outputs are not _identical_ because the printf output has a trailing space, which the echo does not. If you want tab separators, try: printf '%s\t' * If you want something which 100.% works exactly and identically like the BASH "echo" builtin, then you are doomed to disappointment. If you want a replacement for "echo -n", you might try using a function (defined in ~/.bashrc) similar to: function echo-n() { printf '%s ' "$@" | sed -r 's/ $//'; } > > Thanks & Regards > --Jyoti > > -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown
Re: echo -n
On Thu, Feb 02, 2017 at 10:26:22PM +0530, Jyoti B Tenginakai wrote: > I have tried using the printf instead of echo. But the issue with printf > is , the behaviour is not consistent with what echo prints for all the > inputs i.e. But what echo prints is by definition inconsistent across platforms and shells and so on. Make the code do what you want. Do not attempt to make it use a broken command in some consistent way. > In my script I am generically using echo for all the options. Why? What do you want to write to stdout? Figure out what you want to do, then do it. > If I have to > use printf instead of it should behave consistently . printf behaves consistently. > if echo * is passed to bash shell ... what does that mean? Your user is passing a quoted string 'echo *' as an argument? What are you doing, eval'ing user arguments as shell commands? Or do you mean that you have the command echo * in your script? What do you WANT it to do? Do you want it to print the files in $PWD one per line? Blithely ignoring the possibility of filenames that contain newlines? printf '%s\n' * That will print each filename (except dot files, but your original command has the same issue) with a newline after it. If a filename contains a newline, then there will be two newlines produced for that particular filename: the one inside it, and the one added by the printf format spec. > the o/p shows the \t seperated values The who what? What the hell are you talking about now? > whereas with printf '%s' *, it won't display space separated output. You want SPACES now? printf '%s ' * > Again > printf '%s ' # behaviour is different from what echo # shows Are you talking aobut the one trailing space that you'll get from printf '%s ' * vs. echo * ?? Do you actually CARE about ONE SPACE? Do you have an actual GOAL here? Or are you just flailing around randomly until you stumble across some way to bitch about printf? I really hate it when people have a desired answer and then keep flailing around at the English language until they come up with a question that they think will give them their desired answer. In your case, your desired answer is apparently "to run the command echo *". Nobody can possibly satisfy your demands, because you don't have a goal.
Re: echo -n
HI All, Thanks for your quick response. I have tried using the printf instead of echo. But the issue with printf is , the behaviour is not consistent with what echo prints for all the inputs i.e. In my script I am generically using echo for all the options. If I have to use printf instead of it should behave consistently . if echo * is passed to bash shell, the o/p shows the \t seperated values whereas with printf '%s' *, it won't display space separated output. Again printf '%s ' # behaviour is different from what echo # shows Thanks & Regards --Jyoti Jyoti Tenginakai AIX-Security Development Team IBM India Software Lab EGD 'D' Block Sixth Floor Off Indiranagar Koramangala Intermediate Ring Road Bangaluru - 560071 ph: 4177 extn: 7 Mail:jyoti@in.ibm.com From: Pierre Gaston To: Sangamesh Mallayya Cc: "bug-bash@gnu.org" , Jyoti B Tenginakai Date: 02/02/2017 08:45 PM Subject:Re: echo -n On Thu, Feb 2, 2017 at 11:02 AM, Sangamesh Mallayya < sangamesh.sw...@in.ibm.com> wrote: Hi, description: in bash echo -n , echo -e , echo -E has a special meaning. But we do not have a way in bash shell if we want to print -n , -e and -E using echo command. Other shells supports printing of -n/-e/-E options using echo command. For example with ksh # echo -n -n # with bash # echo -n # Please let us know if this a bug or do we have any other option to print -n ? Here is the environment details. version: bash 4.3 Hardware and Operating System P7 AIX Compiled with AIX xlc Thanks, -Sangamesh Not a bug, echo is not portable and posix recommends using printf e.g. printf '%s\n' -n
Re: echo -n
El jue., feb. 2, 2017 9:00 AM, Sangamesh Mallayya < sangamesh.sw...@in.ibm.com> escribió: > [...] > > Please let us know if this a bug or do we have any other option to print > -n ? > Use the printf builtin command. What you encountered is a known limitation of the echo command, as specified by POSIX.
Re: echo -n
On Thu, Feb 2, 2017 at 11:02 AM, Sangamesh Mallayya < sangamesh.sw...@in.ibm.com> wrote: > Hi, > > description: > in bash echo -n , echo -e , echo -E has a special meaning. But we do not > have a way in bash shell if we want to print > -n , -e and -E using echo command. Other shells supports printing of > -n/-e/-E options using echo command. > > For example > > with ksh > # echo -n > -n > # > > with bash > # echo -n > > # > > Please let us know if this a bug or do we have any other option to print > -n ? > > Here is the environment details. > > version: bash 4.3 > Hardware and Operating System P7 AIX > Compiled with AIX xlc > > Thanks, > -Sangamesh > > > > Not a bug, echo is not portable and posix recommends using printf e.g. printf '%s\n' -n
Re: echo -n
On 02/02/2017 03:02 AM, Sangamesh Mallayya wrote: > Hi, > > description: > in bash echo -n , echo -e , echo -E has a special meaning. But we do not > have a way in bash shell if we want to print > -n , -e and -E using echo command. There is NO portable way to print those strings using 'echo'. Use 'printf' instead. POSIX even tells you to do that. > Please let us know if this a bug or do we have any other option to print > -n ? Not a bug. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: echo -n
On Thu, Feb 2, 2017 at 3:02 AM, Sangamesh Mallayya < sangamesh.sw...@in.ibm.com> wrote: > Hi, > > description: > in bash echo -n , echo -e , echo -E has a special meaning. But we do not > have a way in bash shell if we want to print > -n , -e and -E using echo command. Other shells supports printing of > -n/-e/-E options using echo command. > > For example > > with ksh > # echo -n > -n > # > > with bash > # echo -n > > # > > Please let us know if this a bug or do we have any other option to print > -n ? > Well, as another told me "echo is _evil_". You could use "printf" instead: $ printf '%s\n' '-n' -n -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown
Re: echo -n
On Thu, Feb 02, 2017 at 02:32:00PM +0530, Sangamesh Mallayya wrote: > in bash echo -n , echo -e , echo -E has a special meaning. But we do not > have a way in bash shell if we want to print > -n , -e and -E using echo command. Other shells supports printing of > -n/-e/-E options using echo command. Use printf instead of echo. printf '%s\n' "$myvariable" This will work regardless of the contents of the variable. echo is deprecated, and should not be used unless you are certain that it will not be given an argument that could be misinterpreted as an option. E.g. this is fine: echo "You scored $points points." This is not fine: echo "$foo" This was NEVER acceptable and you should not even THINK it: echo $foo
echo -n
Hi, description: in bash echo -n , echo -e , echo -E has a special meaning. But we do not have a way in bash shell if we want to print -n , -e and -E using echo command. Other shells supports printing of -n/-e/-E options using echo command. For example with ksh # echo -n -n # with bash # echo -n # Please let us know if this a bug or do we have any other option to print -n ? Here is the environment details. version: bash 4.3 Hardware and Operating System P7 AIX Compiled with AIX xlc Thanks, -Sangamesh
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On 12/02/2010 07:02 PM, Clark J. Wang wrote: >> The output from the first command in the pipeline does not end with a >> newline. Therefore, 'read' in the second command returns 'failure' >> (non-zero) when it reads the first line of input, and your loop never >> iterates. > > But is that reasonable? I think read should return success in this case > which makes more sense to me. Does the POSIX standards require that? POSIX requires that the input to read be a text file (and by the definition of text file in POSIX, it must either be empty or end in a newline). By violating POSIX and passing something that does not end in a newline, you are no longer bound by the rules of POSIX. Therefore, it would be a reasonable bash extension that read could return 0 status if it read data that did not end in a newline, but it would not be a standard-compliant script that relied on such an extension. You're better off supplying the trailing newline, and guaranteeing a compliant usage. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On Thu, Dec 2, 2010 at 11:49 PM, Greg Wooledge wrote: > On Thu, Dec 02, 2010 at 07:04:57PM +0800, Clark J. Wang wrote: > > Following command also prints nothing, confused :( > > > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do > echo > > $v; done > > The output from the first command in the pipeline does not end with a > newline. Therefore, 'read' in the second command returns 'failure' > (non-zero) when it reads the first line of input, and your loop never > iterates. > But is that reasonable? I think read should return success in this case which makes more sense to me. Does the POSIX standards require that? -- Clark
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On Thu, Dec 02, 2010 at 11:33:24AM -0500, Greg Wooledge wrote: > On Thu, Dec 02, 2010 at 09:29:29AM -0700, Eric Blake wrote: > > On 12/02/2010 04:04 AM, Clark J. Wang wrote: > > > Following command also prints nothing, confused :( > > > > > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo > > > $v; done > > > > http://www.faqs.org/faqs/unix-faq/shell/bash/ > > FAQ E4. > > That was my first thought as well, upon first glance. But that's not > the actual problem here. It's the lack of newline causing read to return > 'failure' even though it does read the input. Yeah, it has bitten me too many times. I keep forgetting it though. -- William
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On Thu, Dec 02, 2010 at 09:29:29AM -0700, Eric Blake wrote: > On 12/02/2010 04:04 AM, Clark J. Wang wrote: > > Following command also prints nothing, confused :( > > > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo > > $v; done > > http://www.faqs.org/faqs/unix-faq/shell/bash/ > FAQ E4. That was my first thought as well, upon first glance. But that's not the actual problem here. It's the lack of newline causing read to return 'failure' even though it does read the input.
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
"Clark J. Wang" writes: > Following command also prints nothing, confused :( > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo > $v; done $ printf . | { read v; echo $?; } 1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On Thu, Dec 02, 2010 at 07:04:57PM +0800, Clark J. Wang wrote: > Following command also prints nothing, confused :( > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo > $v; done The output from the first command in the pipeline does not end with a newline. Therefore, 'read' in the second command returns 'failure' (non-zero) when it reads the first line of input, and your loop never iterates.
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On 12/02/2010 12:04 PM, Clark J. Wang wrote: Following command also prints nothing, confused :( for ((i = 0; i< 10; ++i)); do echo -n " $i"; done | while read v; do echo $v; done read wants to read one line, but you don't end your line. try this two examples: $ printf '1 2 3 4' | while read v; do echo $v; done $ printf '1 2 3 4\n' | while read v; do echo $v; done RR
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On 12/02/2010 04:04 AM, Clark J. Wang wrote: > Following command also prints nothing, confused :( > > for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo > $v; done http://www.faqs.org/faqs/unix-faq/shell/bash/ FAQ E4. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Why `echo -n hello | while read v; do echo $v; done' prints nothing?
Following command also prints nothing, confused :( for ((i = 0; i < 10; ++i)); do echo -n " $i"; done | while read v; do echo $v; done -- Clark
Re: [bash 3.1.5] sh -c "echo -n ok" broken
> So, it is possible to have both the following working in "sh" and "bash" > > echo -n "ok" > echo "ok\c" No. In posix mode, they are fundamentally incompatible. The combination of posix mode and xpg-echo cause bash to be strictly posix compliant and disable any option processing. This is item `c' in the New Features section of NEWS. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [bash 3.1.5] sh -c "echo -n ok" broken
On Thu, 19 Jan 2006, Jeff Chua wrote: On Wed, 18 Jan 2006, Chet Ramey wrote: Somehow you've enabled the xpg_echo option, either by configuring with --enable-xpg-echo-default or running `shopt -s xpg_echo' somewhere. I suspect the former. Yes, I did "--enable-xpg-echo-default" as I need echo "ok\c" to work. The older bash-3.00.15(3) works with "--enable-xpg-echo-default". So, it is possible to have both the following working in "sh" and "bash" echo -n "ok" echo "ok\c" printf "%s" "ok" -- Chris F.A. Johnson <http://cfaj.freeshell.org> === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [bash 3.1.5] sh -c "echo -n ok" broken
On Wed, 18 Jan 2006, Chet Ramey wrote: Somehow you've enabled the xpg_echo option, either by configuring with --enable-xpg-echo-default or running `shopt -s xpg_echo' somewhere. I suspect the former. Yes, I did "--enable-xpg-echo-default" as I need echo "ok\c" to work. The older bash-3.00.15(3) works with "--enable-xpg-echo-default". So, it is possible to have both the following working in "sh" and "bash" echo -n "ok" echo "ok\c" Thanks, Jeff. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[bash 3.1.5] sh -c "echo -n ok" broken
GNU bash, version 3.1.5(1)-release sh -c "echo -n ok" returns "-n ok". This breaks a lot of scripts ... startup scripts in /etc/rc.d and many packages like glibc "make check" that use "sh" instead of "bash" with "-n" option. How can I make sh -c "echo -n ok" returns "ok" instead "-n ok"? I've tried compiling with --disable-strict-posix-default but that doesn't work. Thanks, Jeff ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [bash 3.1.5] sh -c "echo -n ok" broken
Jeff Chua wrote: > > GNU bash, version 3.1.5(1)-release > > sh -c "echo -n ok" returns "-n ok". > > This breaks a lot of scripts ... startup scripts in /etc/rc.d and many > packages like glibc "make check" that use "sh" instead of "bash" with > "-n" option. > > How can I make sh -c "echo -n ok" returns "ok" instead "-n ok"? > > I've tried compiling with --disable-strict-posix-default but that > doesn't work. It doesn't behave that way by default: z3.local(1)$ ./sh --version GNU bash, version 3.1.5(2)-release (powerpc-apple-darwin8.3.0) Copyright (C) 2005 Free Software Foundation, Inc. z3.local(1)$ ./sh -c 'echo -n ok' okz3.local(1)$ Somehow you've enabled the xpg_echo option, either by configuring with --enable-xpg-echo-default or running `shopt -s xpg_echo' somewhere. I suspect the former. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [bash 3.1.5] sh -c "echo -n ok" broken
On Wednesday 18 January 2006 18:34, Jeff Chua wrote: > GNU bash, version 3.1.5(1)-release > > sh -c "echo -n ok" returns "-n ok". works correctly for me: [EMAIL PROTECTED] 0 ~ $ sh -c "echo -n ok" [EMAIL PROTECTED] 0 ~ $ -mike ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash