echo "-n"

[Hongyi Zhao]

Hi all,

I want to use echo to print some stuff which maybe included in its args,
say, `-n', how should I do?

The following commands will fail for this job:

werner@debian:~$ echo -n
werner@debian:~$ echo "-n"
werner@debian:~$ echo '-n'

Any hints?

Regards
--
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.

[Bit Twister]

On Mon, 13 Apr 2015 04:26:07 +0000 (UTC), Hongyi Zhao wrote:
> Hi all,
>
> I want to use echo to print some stuff which maybe included in its args,
> say, `-n', how should I do?

Do you mean something like

junk=" -n -e"
echo "$junk"
-n -e

junk="-n -e whatever"
echo "$junk"
-n -e whatever

As for your problem.

junk="-n"
if [ "$junk" = "-n" ] ; then
junk="$junk "
fi

echo "$junk"
-n

[Kaz Kylheku]

On 2015-04-13, Hongyi Zhao <hongy...@gmail.com> wrote:
> Hi all,
>
> I want to use echo to print some stuff which maybe included in its args,
> say, `-n', how should I do?
>
> The following commands will fail for this job:
>
> werner@debian:~$ echo -n
> werner@debian:~$ echo "-n"
> werner@debian:~$ echo '-n'

These methods are equivalent because echo does not process the quoting. The
shell processes the quotes and in all three cases invokes echo with an argument
consisting of the two-character string -n.

There is no portable way to suppress the treatment of -n as an option.

The Single Unix Specification says very clearly:

The echo utility shall not recognize the "--" argument in the manner
specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall be
recognized as a string operand.

So we cannot use

echo -- -n

Moreover, curiously, the specification says that:

Implementations shall not support any options.

However, then in the following section it says that:

If the first operand is -n, or if any of the operands contain a <backslash>
character, the results are implementation-defined.

Never mind that; the most important texts are in the APPLICATION USAGE section:

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): [... examples given ...]

And the most important "take home message":

New applications are encouraged to use printf instead of echo.

Thus, for instance:

printf "%s\n" -n
printf -- "-n\n"

[Hongyi Zhao]

On Mon, 13 Apr 2015 04:56:56 +0000, Bit Twister wrote:

> junk="-n"
> if [ "$junk" = "-n" ] ; then
> junk="$junk "
> fi
>
> echo "$junk"
> -n

Not work for my Debian Wheezy:

werner@debian:~$ junk="-n"
werner@debian:~$ echo "$junk"
werner@debian:~$

The echo command gives nothing, as you can see.

[Hongyi Zhao]

On Mon, 13 Apr 2015 05:03:04 +0000, Kaz Kylheku wrote:

> Thus, for instance:
>
> printf "%s\n" -n printf -- "-n\n"

Thanks for this method.

[Hongyi Zhao]

On Mon, 13 Apr 2015 05:03:04 +0000, Kaz Kylheku wrote:

> Thus, for instance:
>
> printf "%s\n" -n printf -- "-n\n"

Based on your hints, I've tried some more stuff, say, the following ones:


werner@debian:~$ printf -- "-n \\fds \\\n"
-n
ds \nwerner@debian:~$

As you can see, it gives so strange outputs. I've inspect the manpage,
but cann't find glues to give a clearly explanation on this thing. Any
hints.

[Bit Twister]

On Mon, 13 Apr 2015 05:18:18 +0000 (UTC), Hongyi Zhao wrote:
> On Mon, 13 Apr 2015 04:56:56 +0000, Bit Twister wrote:
>
>> junk="-n"
>> if [ "$junk" = "-n" ] ; then
>> junk="$junk "
>> fi
>>
>> echo "$junk"
>> -n
>
> Not work for my Debian Wheezy:
>
> werner@debian:~$ junk="-n"
> werner@debian:~$ echo "$junk"
> werner@debian:~$
>
> The echo command gives nothing, as you can see.

For someone who it trying to learn bash you failed to just paste my
suggestion into a terminal and see what happens let alone analyze what
the code does. Here try pasting this into a terminal and see what happens.

[Kaz Kylheku]

On 2015-04-13, Hongyi Zhao <hongy...@gmail.com> wrote:

> On Mon, 13 Apr 2015 05:03:04 +0000, Kaz Kylheku wrote:
>
>> Thus, for instance:
>>
>> printf "%s\n" -n printf -- "-n\n"
>
> Based on your hints, I've tried some more stuff, say, the following ones:
>
>
> werner@debian:~$ printf -- "-n \\fds \\\n"
> -n
> ds \nwerner@debian:~$
>
> As you can see, it gives so strange outputs. I've inspect the manpage,
> but cann't find glues to give a clearly explanation on this thing. Any
> hints.

You have to understand the handling of \ escapes in double quotes.

"\\f" denotes the text \f, because two \\ characters denote a single \ character.

So printf sees \f and converts it to the formfeed character.

"\\\n" denotes the text \\n. This is because first two \\ codes for a single \.
A \ followed by n is literal; \n just denotes \n.

So what goes into printf is \\n, and now printf treats \\ as a single \, and n
as literal: it outputs \n.

If you want to see what arguments are going into a command try:

for x in .. your args go here .. ; do
printf "<%s>\n" "$x"
done

for example, let's try your printf arguments:

$ for x in -- "-n \\fds \\\n" ; do printf "<%s>\n" "$x" ; done
<-->
<-n \fds \\n>

So, aha, what goes into printf is -- and -n \fds \\n

[Chris F.A. Johnson]

On 2015-04-13, Hongyi Zhao wrote:
> On Mon, 13 Apr 2015 05:03:04 +0000, Kaz Kylheku wrote:
>
>> Thus, for instance:
>>
>> printf "%s\n" -n printf -- "-n\n"
>
> Based on your hints, I've tried some more stuff, say, the following ones:
>
>
> werner@debian:~$ printf -- "-n \\fds \\\n"
> -n
> ds \nwerner@debian:~$
>
> As you can see, it gives so strange outputs. I've inspect the manpage,
> but cann't find glues to give a clearly explanation on this thing. Any
> hints.

The first argument to printf is a format string. Use:

printf "%s\n" whatever

--
Chris F.A. Johnson

[Hongyi Zhao]

On Mon, 13 Apr 2015 06:32:14 +0000, Bit Twister wrote:

> For someone who it trying to learn bash you failed to just paste my
> suggestion into a terminal and see what happens let alone analyze what
> the code does. Here try pasting this into a terminal and see what
> happens.
>
> junk="-n"
> if [ "$junk" = "-n" ] ; then
> junk="$junk "

Why it must use a space in the "$junk "?

I've tried the following one it also gives nothing:

werner@debian:~$ junk="-n"
werner@debian:~$ if [ "$junk" = "-n" ] ; then junk="$junk"; echo "$junk";
fi
werner@debian:~$


> fi
>
> echo "$junk"

[Hongyi Zhao]

On Mon, 13 Apr 2015 06:41:10 +0000, Kaz Kylheku wrote:

> for example, let's try your printf arguments:
>
> $ for x in -- "-n \\fds \\\n" ; do printf "<%s>\n" "$x" ; done <-->
> <-n \fds \\n>
>
> So, aha, what goes into printf is -- and -n \fds \\n

So, in this case, the actual command processed by printf innerly is this:

printf -- -n \fds \\n

The -- told printf not treat anything as args/options after this symbol.

And so, I analysis it as follows:

-n goes out as -n;
\f is a non-printable control character -- formfeed -- and will be
garbled or nothing in the output;
ds will goes out as ds;
\\ once again, the first \ will escape the second one, and goes out a
literal \;
n goes out as n.

Finally, I got the following things:

-n <formfeed>ds \n

Am I right?

Furthermore, I do the following testings on echo:

werner@debian:~$ echo "-n"
werner@debian:~$ echo "-n "
-n

werner@debian:~$ echo "-n \\fds \\\n"
-n \fds \\n

As you can see, the last two commands work, but the first one does
nothing. Why?

[Kaz Kylheku]

The space is in the output, so no cigar:

$ capture=$(echo "-n ")
$ printf "<%s>\n" "$capture"
<-n >

Also, this approach looks like a -n option has been clumped with a -<space>
option. The fallback behavior of your echo is handling unrecognized options by
just dumping the whole combination of option characters, including the dash, as
a literal:

$ echo -ne foo
foo$ echo -nZ foo
-nZ
$

This approach could still screw up on some option-enhanced implementation of
echo which use getopt and recognizes clumped options, and do not have this
fallback behavior for unexpected options.

[Kaz Kylheku]

On 2015-04-13, Hongyi Zhao <hongy...@gmail.com> wrote:

> On Mon, 13 Apr 2015 06:41:10 +0000, Kaz Kylheku wrote:
>
>> for example, let's try your printf arguments:
>>
>> $ for x in -- "-n \\fds \\\n" ; do printf "<%s>\n" "$x" ; done <-->
>> <-n \fds \\n>
>>
>> So, aha, what goes into printf is -- and -n \fds \\n
>
> So, in this case, the actual command processed by printf innerly is this:

If printf is a program in /usr/bin rather than a shell builtin, it's quite externly. :)

> printf -- -n \fds \\n
>
> The -- told printf not treat anything as args/options after this symbol.

Yes. This is not explicitly required by POSIX, by the way. POSIX says that printf
takes no options.

However, even if a command takes no options, the requirement to support -- applies,
because:

The first -- argument that is not an option-argument should be accepted as a
delimiter indicating the end of options. Any following arguments should be
treated as operands, even if they begin with the '-' character.

For a command which takes no options, -- is a "non-option argument".

Actual implementations of printf have options. Bash builtin:

$ printf --version
bash: printf: --: invalid option
printf: usage: printf [-v var] format [arguments]

Coreutils printf:

$ /usr/bin/printf --version
printf (GNU coreutils) 8.13
[ ... etc ]

> And so, I analysis it as follows:
>
> -n goes out as -n;
> \f is a non-printable control character -- formfeed -- and will be
> garbled or nothing in the output;

If the output is a terminal, it can actually do something, like clear
the screen. On a line printer, it can eject the page.

> ds will goes out as ds;
> \\ once again, the first \ will escape the second one, and goes out a
> literal \;
> n goes out as n.
>
> Finally, I got the following things:
>
> -n <formfeed>ds \n
>
> Am I right?

That's it. Basically, very similar to what the C printf would do.

> Furthermore, I do the following testings on echo:
>
> werner@debian:~$ echo "-n"
> werner@debian:~$ echo "-n "
> -n
> werner@debian:~$ echo "-n \\fds \\\n"
> -n \fds \\n
>
> As you can see, the last two commands work, but the first one does
> nothing. Why?

Probably because the echo command has fallback logic for any unrecognized
option character.

Try

echo -ne

(e is recognized by your echo) versus

echo -nZ

(Z is not recognized; and so the behavior of -n is suppressed too and the
entire argument is just printed.)

The "-n " argument is proably being regarded by your echo as the options -n and
-<space> specified together as a clump.

None of this is specified in the standard however. I think that your implementors
either don't care about standard conformance, or are interpreting the standard
as meaning that if -n is present in the first argument even as a clump,
the behavior is implementation-defined.

(My reading is that the specification only concerns itself whether or not -n is
literally the first argument, not whether or not it is a member of a clump like
-ne or -nZ; but that interpretation forbids supporting additional options like -e.)

[Kaz Kylheku]

On 2015-04-13, Kaz Kylheku <k...@kylheku.com> wrote:
> And the most important "take home message":
>
> New applications are encouraged to use printf instead of echo.
>
> Thus, for instance:
>
> printf "%s\n" -n
> printf -- "-n\n"

If you can rely on your echo supporting the -n option, then this may also be
possible:

echo -n - ; echo n
-n

If you don't care about portability at all, and just want the "-n ..." output
on your system, using the echo command:

echo -e '\x2Dn'

[Hongyi Zhao]

On Mon, 13 Apr 2015 14:16:15 +0000, Kaz Kylheku wrote:

> Actual implementations of printf have options. Bash builtin:
>
> $ printf --version bash: printf: --: invalid option printf: usage:
> printf [-v var] format [arguments]
>
> Coreutils printf:
>
> $ /usr/bin/printf --version printf (GNU coreutils) 8.13 [ ... etc ]

But, the printf command will directly invoke the /usr/bin/printf, why
they give the different information with `--version'?

See the following for detail on my Debian Wheezy box:

-----------------
werner@debian:~$ which printf
/usr/bin/printf

werner@debian:~$ printf --version

bash: printf: --: invalid option
printf: usage: printf [-v var] format [arguments]

werner@debian:~$ /usr/bin/printf --version
printf (GNU coreutils) 8.13
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
----------------

[Kaz Kylheku]

On 2015-04-14, Hongyi Zhao <hongy...@gmail.com> wrote:
> On Mon, 13 Apr 2015 14:16:15 +0000, Kaz Kylheku wrote:
>
>> Actual implementations of printf have options. Bash builtin:
>>
>> $ printf --version bash: printf: --: invalid option printf: usage:
>> printf [-v var] format [arguments]
>>
>> Coreutils printf:
>>
>> $ /usr/bin/printf --version printf (GNU coreutils) 8.13 [ ... etc ]
>
> But, the printf command will directly invoke the /usr/bin/printf, why
> they give the different information with `--version'?

Because there really are two implementations of printf. GNU Bash has a
built-in printf command which doesn't invoke /usr/bin/printf or anything else
in the PATH, and there is also a printf program in GNU Coreutils.

> werner@debian:~$ which printf
> /usr/bin/printf

Try "type printf", instead of "which printf".

which is *not* a Bash built-in command so of course it doesn't "see"
commands. It reports on what programs resolve via PATH.

"which" is not a POSIX command either.

On a Debian system, this program comes from a package called "debianutils".

It likely a "C-shell-ism" implemented as an external command, probably for the
sake of ex-C-shell-users who are unable to unlearn it and use "type" instead.

(I dropped the habit of using "which" in the early to mid 1990's, when I quit
using the C shell and all its derivatives.)

The type command *is* POSIX. Though POSIX does not describe any options for it,
in Bash, the "which" behavior if you need it (search executable PATH only, not
functions, builtin commands or aliases) can be obtained with "type -P ...".

[Bit Twister]

On Tue, 14 Apr 2015 02:09:57 +0000 (UTC), Kaz Kylheku wrote:
>
> The type command *is* POSIX. Though POSIX does not describe any options for it,
> in Bash, the "which" behavior if you need it (search executable PATH only, not
> functions, builtin commands or aliases) can be obtained with "type -P ...".

Snippet from man bash.

BASH BUILTIN COMMANDS
Unless otherwise noted, each builtin command documented in this section
as accepting options preceded by - accepts -- to signify the end of the
options. The :, true, false, and test builtins do not accept options
and do not treat -- specially. The exit, logout, break, continue, let,
and shift builtins accept and process arguments beginning with - with‐
type [-aftpP] name [name ...]
With no options, indicate how each name would be interpreted if
used as a command name. If the -t option is used, type prints a
string which is one of alias, keyword, function, builtin, or
file if name is an alias, shell reserved word, function,
builtin, or disk file, respectively. If the name is not found,
then nothing is printed, and an exit status of false is
returned. If the -p option is used, type either returns the
name of the disk file that would be executed if name were speci‐
fied as a command name, or nothing if ``type -t name'' would not
return file. The -P option forces a PATH search for each name,
even if ``type -t name'' would not return file. If a command is
hashed, -p and -P print the hashed value, which is not necessar‐
ily the file that appears first in PATH. If the -a option is
used, type prints all of the places that contain an executable
named name. This includes aliases and functions, if and only if
the -p option is not also used. The table of hashed commands is
not consulted when using -a. The -f option suppresses shell
function lookup, as with the command builtin. type returns true
if all of the arguments are found, false if any are not found.

[Geoff Clare]

Kaz Kylheku wrote:

> However, even if a command takes no options, the requirement to
> support -- applies, because:
>
> The first -- argument that is not an option-argument should be
> accepted as a delimiter indicating the end of options. Any following
> arguments should be treated as operands, even if they begin with the
> '-' character.
>
> For a command which takes no options, -- is a "non-option argument".

True, but that's not what "not an option-argument" means in that
POSIX quote. An option-argument is an argument-to-an-option, not
an argument that is an option. E.g. in "grep -e foo", foo is an
option-argument. The point of that part of the text is that in
"grep -e -- -e bar" the "--" is not an end-of-options delimiter.

--
Geoff Clare <net...@gclare.org.uk>

[Hongyi Zhao]

On Tue, 14 Apr 2015 13:44:49 +0100, Geoff Clare wrote:

> The point of that part of the text is that in "grep -e -- -e bar"

What does this command mean?

> the
> "--" is not an end-of-options delimiter.

Then what's it stand for?

[Kaz Kylheku]

On 2015-04-14, Hongyi Zhao <hongy...@gmail.com> wrote:

> On Tue, 14 Apr 2015 13:44:49 +0100, Geoff Clare wrote:
>
>> The point of that part of the text is that in "grep -e -- -e bar"
>
> What does this command mean?
>
>> the
>> "--" is not an end-of-options delimiter.
>
> Then what's it stand for?

It is the argument to the -e option, which takes a pattern.

[Hongyi Zhao]

On Tue, 14 Apr 2015 23:21:34 +0000, Kaz Kylheku wrote:


> It is the argument to the -e option, which takes a pattern.

Then do you mean for the following special case when using grep on files
like this:


werner@debian:~$ printf "%s-e bar" > aaa
werner@debian:~$ grep -e -- -e bar aaa
-e bar

But, all of the following commands will fail to work:

werner@debian:~$ grep -e -- "-e" aaa
^C
werner@debian:~$ grep -e -- "-e" aaa
^C
werner@debian:~$ grep -e -- "bar" aaa
grep: bar: No such file or directory


And the following one can do the trick:

werner@debian:~$ grep -e -- "-e " aaa
-e bar

[Hongyi Zhao]

On Wed, 15 Apr 2015 01:34:33 +0000, Hongyi Zhao wrote:

> And the following one can do the trick:
>
> werner@debian:~$ grep -e -- "-e " aaa -e bar

Also, the following ones will work too:

werner@debian:~$ grep -- -e aaa
-e bar
werner@debian:~$ grep -- bar aaa

[Kaz Kylheku]

On 2015-04-15, Hongyi Zhao <hongy...@gmail.com> wrote:
> On Tue, 14 Apr 2015 23:21:34 +0000, Kaz Kylheku wrote:
>
>
>> It is the argument to the -e option, which takes a pattern.
>
> Then do you mean for the following special case when using grep on files
> like this:
>
>
> werner@debian:~$ printf "%s-e bar" > aaa

> werner@debian:~$ grep -e -- -e bar aaa
> -e bar
>
> But, all of the following commands will fail to work:
>
> werner@debian:~$ grep -e -- "-e" aaa

The quoting here does nothing, as has been explained in another situation.

Quoting does not prevent the special treatment of an operand by a program;
it suppresses the splitting of words on spaces to make separate arguments,
and suppresses pathname expansions.

Quotes are stripped away by the shell, leaving the argument -e. This command
line is exactly the same as

grep -e -- -e aaa

You really must understand how the shell processes a command line: what
processing is done by the shell to produce the arguments.

When in doubt about how some arguments are delimited, chopped up and expanded,
write a loop:

for arg in grep -e -- "-e" aaa ; do
# ^^^^^^^^^^^^^^^^^^^ exact command line goes here
printf "[%s]\n" "$arg"
done

the same processing is performed for the arguments of the for ... do command as
for an ordinary command.

[Ben Bacarisse]

Kaz Kylheku <k...@kylheku.com> writes:
<snip>

> When in doubt about how some arguments are delimited, chopped up and expanded,
> write a loop:
>
> for arg in grep -e -- "-e" aaa ; do
> # ^^^^^^^^^^^^^^^^^^^ exact command line goes here
> printf "[%s]\n" "$arg"
> done

I use the fact that printf re-uses the format and simply write:

printf "[%s]\n" grep -e -- "-e" aaa

when I'm in doubt about quoting or splitting. There may be a benefit to
the loop version, but I can't think of one off the top of my head.

--
Ben.

[Kenny McCormack]

In article <87k2xdi...@bsb.me.uk>,

That's really clever. I can use that.

Given the number of times I've written a "VerboseEcho" type program, in
various languages, knowing this technique will be a real benefit.

--

There are many self-professed Christians who seem to think that because
they believe in Jesus' sacrifice they can reject Jesus' teachings about
how we should treat others. In this country, they show that they reject
Jesus' teachings by voting for Republicans.

[Geoff Clare]

Hongyi Zhao wrote:

> On Tue, 14 Apr 2015 13:44:49 +0100, Geoff Clare wrote:
>
>> The point of that part of the text is that in "grep -e -- -e bar"
>
> What does this command mean?

It tells grep to search for lines on standard input that
match either the string "--" or the string "bar":

$ printf '%s\n' xyz-- xyzfoo xyzbar | grep -e -- -e bar
xyz--
xyzbar

>> the
>> "--" is not an end-of-options delimiter.
>
> Then what's it stand for?

It's an option-argument for the -e option, i.e. a pattern (regular
expression) to search for.

--
Geoff Clare <net...@gclare.org.uk>

[Stephane Chazelas]

2015-04-13 04:26:07 +0000, Hongyi Zhao:

> Hi all,
>
> I want to use echo to print some stuff which maybe included in its args,
> say, `-n', how should I do?
>
> The following commands will fail for this job:
>

> werner@debian:~$ echo -n
> werner@debian:~$ echo "-n"

> werner@debian:~$ echo '-n'
>
> Any hints?
[...]

Those 3 commands run echo with the same 2 argument ("echo" and
"-n" (without the quotes)).

POSIXly:

you cannot use echo.

printf -- '-n\n'

http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo

expr -- -n

basename /-n

dirname -- -n/x

date +-n

cat <<EOF
-n
EOF

awk 'BEGIN{print "-n"}'



UNIXly (POSIX with XSI extension):

All of the above and:

echo -n

For bash's echo to behave UNIXly:

(set -o posix; shopt -s xpg_echo; echo -n)

--
Stephane

[Hongyi Zhao]

On Mon, 20 Apr 2015 21:04:34 +0100, Stephane Chazelas wrote:


> Those 3 commands run echo with the same 2 argument ("echo" and "-n"
> (without the quotes)).
>
> POSIXly:
>
> you cannot use echo.
>
> printf -- '-n\n'
>
> http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-
echo
>
> expr -- -n
>
> basename /-n
>
> dirname -- -n/x
>
> date +-n
>
> cat <<EOF -n EOF
>
> awk 'BEGIN{print "-n"}'
>
>
>
> UNIXly (POSIX with XSI extension):
>
> All of the above and:
>
> echo -n
>
> For bash's echo to behave UNIXly:
>
> (set -o posix; shopt -s xpg_echo; echo -n)

Thanks a lot for your deeply explained notes and hints.