Re: echo -n

[Peter & Kelly Passchier]

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
> > 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

[Jyoti B Tenginakai]

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: Readline macro definition with multibyte characters

[Chet Ramey]

On 2/4/17 9:07 PM, Grisha Levit wrote:
> The character-search command accepts multibyte characters just fine, but
> when reading input from a macro, multibyte characters are not processed
> correctly. For example trying to invoke the macro defined with:
> 
> bind '"\C-f": "\C-]π"'
> 
> will fail to search and will instead type just the second byte of the
> character (x80).
> 
> The following one-line patch fixes the behavior, but I'm not sure if this
> the right place to do it.

Thanks for the report.  It's a good fix.  rl_read_key should return all
valid characters as if they are unsigned chars and reserve values < 0
for EOF and errors.

Chet

-- 
``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/