This is odd. I had seen the echo.c from some BSD system in the past. I
don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
was OpenBSD because OpenBSD's source still behaves I remember it.
Here's the behavior.

%echo -n -n hello
hello%

Notice that the -n seems to have been processed twice, which is why we
don't see a -n. However, that's not the behavior you find when you
interpret its source code at

https://cvsweb.openbsd.org/src/bin/echo/echo.c

I've looked at all revisions there. They're all essentially the same.
The behavior written in C in the URL above is essentially this:

%./openbsd-echo -n -n hello
-n hello%

So, what's up with that?

I remember this well because when I read it for the first time, there
was a loop looking for -n, which prompted me to ask --- omg, how am I
going to print ``-n'' to the terminal? A friend eventually gave me a
nice solution. I also recall Brian Kernighan discussing this problem in
the UNIX Programming Environment as his solution was equally nice, but
different. This must mean that Brian Kernighan was also aware of
echo-programs with such behavior and so my memory is not really failing
me.

Meredith Montgomery <mmontgomery@levado.to> wrote:
> This is odd. I had seen the echo.c from some BSD system in the past. I
> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
> was OpenBSD because OpenBSD's source still behaves I remember it.
> Here's the behavior.
>
> %echo -n -n hello
> hello%
>
<snip>

> I've looked at all revisions there. They're all essentially the same.
> The behavior written in C in the URL above is essentially this:
>
> %./openbsd-echo -n -n hello
> -n hello%
>
> So, what's up with that?

/bin/echo and builtins with csh(1), tcsh(1)and ksh(1)
on OpenBSD prints:
-n hello

Are you sure it was not some builtin from another or older
shell ?

<snip>

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

Meredith Montgomery <mmontgomery@levado.to> writes:
> This is odd. I had seen the echo.c from some BSD system in the past. I
> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
> was OpenBSD because OpenBSD's source still behaves I remember it.
> Here's the behavior.
>
> %echo -n -n hello
> hello%

[...]

Both the GNU /bin/echo and the bash builtin also behave in this way. The
(d)ash one doesn't.

> I remember this well because when I read it for the first time, there
> was a loop looking for -n, which prompted me to ask --- omg, how am I
> going to print ``-n'' to the terminal?

The solution to this is usually 'use printf(1)' which behaves in a sane
way.

Rainer Weikusat <rweikusat@talktalk.net> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>> This is odd. I had seen the echo.c from some BSD system in the past. I
>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>> was OpenBSD because OpenBSD's source still behaves I remember it.
>> Here's the behavior.
>>
>> %echo -n -n hello
>> hello%
>
> [...]
>
> Both the GNU /bin/echo and the bash builtin also behave in this way. The
> (d)ash one doesn't.

I guess /bin/sh on OpenBSD does as well. I've been fooled thinking I
was running /bin/echo when I was running ``builtin echo'' of /bin/sh on
OpenBSD.

>> I remember this well because when I read it for the first time, there
>> was a loop looking for -n, which prompted me to ask --- omg, how am I
>> going to print ``-n'' to the terminal?
>
> The solution to this is usually 'use printf(1)' which behaves in a sane
> way.

Indeed. Much better.

Why would anyone do an echo program like that? Where they initially
thinking that they would support lots of flags and therefore parse the
entire argv?

Meredith Montgomery <mmontgomery@levado.to> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> This is odd. I had seen the echo.c from some BSD system in the past. I
>>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>>> was OpenBSD because OpenBSD's source still behaves I remember it.
>>> Here's the behavior.
>>>
>>> %echo -n -n hello
>>> hello%
>>
>> [...]
>>
>> Both the GNU /bin/echo and the bash builtin also behave in this way. The
>> (d)ash one doesn't.

[...]

> Why would anyone do an echo program like that? Where they initially
> thinking that they would support lots of flags and therefore parse the
> entire argv?

Compatibility with existing code, most likely. Judging from comments in
the GNU echo.c, they were aiming for compatibility with the /bin/sh
builtin echo of V9 Research UNIX said to be distributed as part of
SysV.

Apart from that, that's the usual convention: Silently process any number of
repeated options. For boolean options, that's not going to change
anything. OTOH, one has to handle this situation somehow and this
approach is easy to implement and semantically perfectly reasonable
(enabling something that's already enabled is a harmles nop). The issue
with the GNU echo.c is really just that they do their own option parsing
(ie, they don't use getopt) and don't follow the usual
convention of using -- to denote the end of the option list.

Eg,

[rw@doppelsaurus]~#printf -n
bash: printf: -n: invalid option
printf: usage: printf [-v var] format [arguments]

but

[rw@doppelsaurus]~#printf -- -n
-n[rw@doppelsaurus]~#

John McCue <jmccue@fuzzball.mhome.org> writes:

> Meredith Montgomery <mmontgomery@levado.to> wrote:
>> This is odd. I had seen the echo.c from some BSD system in the past. I
>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>> was OpenBSD because OpenBSD's source still behaves I remember it.
>> Here's the behavior.
>>
>> %echo -n -n hello
>> hello%
>>
> <snip>
>
>> I've looked at all revisions there. They're all essentially the same.
>> The behavior written in C in the URL above is essentially this:
>>
>> %./openbsd-echo -n -n hello
>> -n hello%
>>
>> So, what's up with that?
>
> /bin/echo and builtins with csh(1), tcsh(1)and ksh(1)
> on OpenBSD prints:
> -n hello
>
> Are you sure it was not some builtin from another or older
> shell ?

It was a builtin. I was totally fooled by it. For years because for
years I've been thinking that some BSD echo was weird. I'm curious now
as to why GNU echo loops through argv. (The only thing I can think of
is that it was plans for the future --- new flags and so on. But POSIX
requires only -n and as a first argument --- IIRC.)

Meredith Montgomery <mmontgomery@levado.to> writes:

> John McCue <jmccue@fuzzball.mhome.org> writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> wrote:
>>> This is odd. I had seen the echo.c from some BSD system in the past. I
>>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>>> was OpenBSD because OpenBSD's source still behaves I remember it.
>>> Here's the behavior.
>>>
>>> %echo -n -n hello
>>> hello%
>>>
>> <snip>
>>
>>> I've looked at all revisions there. They're all essentially the same.
>>> The behavior written in C in the URL above is essentially this:
>>>
>>> %./openbsd-echo -n -n hello
>>> -n hello%
>>>
>>> So, what's up with that?
>>
>> /bin/echo and builtins with csh(1), tcsh(1)and ksh(1)
>> on OpenBSD prints:
>> -n hello
>>
>> Are you sure it was not some builtin from another or older
>> shell ?
>
> It was a builtin. I was totally fooled by it. For years because for
> years I've been thinking that some BSD echo was weird. I'm curious now
> as to why GNU echo loops through argv. (The only thing I can think of
> is that it was plans for the future --- new flags and so on. But POSIX
> requires only -n and as a first argument --- IIRC.)

I did not recall correctly. The -n as a first argument is
implementation-defined. ``If the first operand is -n, or if any of the
operands contain a <backslash> character, the results are
implementation-defined.'' -- IEEE Std 1003.1-2017

Rainer Weikusat <rweikusat@talktalk.net> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>> This is odd. I had seen the echo.c from some BSD system in the past. I
>>>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>>>> was OpenBSD because OpenBSD's source still behaves I remember it.
>>>> Here's the behavior.
>>>>
>>>> %echo -n -n hello
>>>> hello%
>>>
>>> [...]
>>>
>>> Both the GNU /bin/echo and the bash builtin also behave in this way. The
>>> (d)ash one doesn't.
>
> [...]
>
>> Why would anyone do an echo program like that? Where they initially
>> thinking that they would support lots of flags and therefore parse the
>> entire argv?
>
> Compatibility with existing code, most likely. Judging from comments in
> the GNU echo.c, they were aiming for compatibility with the /bin/sh
> builtin echo of V9 Research UNIX said to be distributed as part of
> SysV.

Thank you!

> Apart from that, that's the usual convention: Silently process any number of
> repeated options. For boolean options, that's not going to change
> anything. OTOH, one has to handle this situation somehow and this
> approach is easy to implement and semantically perfectly reasonable
> (enabling something that's already enabled is a harmles nop). The issue
> with the GNU echo.c is really just that they do their own option parsing
> (ie, they don't use getopt) and don't follow the usual
> convention of using -- to denote the end of the option list.

Yes, most likely because of POSIX? Or should I say ``IEEE Std 1003.1-2017''?

--8<---------------cut here---------------start------------->8---
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.

Implementations shall not support any options.
--8<---------------cut here---------------end--------------->8---

> Eg,
>
> [rw@doppelsaurus]~#printf -n
> bash: printf: -n: invalid option
> printf: usage: printf [-v var] format [arguments]
>
> but
>
>
> [rw@doppelsaurus]~#printf -- -n
> -n[rw@doppelsaurus]~#

Thank you!

Meredith Montgomery <mmontgomery@levado.to> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:

[...]

>> The issue with the GNU echo.c is really just that they do their own
>> option parsing (ie, they don't use getopt) and don't follow the usual
>> convention of using -- to denote the end of the option list.
>
> Yes, most likely because of POSIX? Or should I say ``IEEE Std 1003.1-2017''?
>
> 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.
>
> Implementations shall not support any options.

That's a bit of a moot point as the GNU echo isn't compliant with this,
anyway: They suppport -E, -e and -n as options if nothing else starting
with a hyphen was found on the command-line before it, eg,

rw@brushfire:~/work/cadaptSuricataRulesUpdate$ echo -a -n
-a -n

and they don't support escape sequences unless POSIXLY_CORRECT was set
in the environment or either -e or -E appeared on the command-line while
the program was still looking for options.

Compatibility with SysV quirks may have been a worthwhile feature in the
1990s, but nowadays, pretty much nothing but echoes of its quirks in
other software remains from it.

On 2021-11-24, Meredith Montgomery <mmontgomery@levado.to> wrote:
> This is odd. I had seen the echo.c from some BSD system in the past. I
> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
> was OpenBSD because OpenBSD's source still behaves I remember it.
> Here's the behavior.
>
> %echo -n -n hello
> hello%

According to POSIX, echo doesn't take any options, including the --
option to end options. See here:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

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.

Implementations shall not support any options.

Thus, "echo -n -n hello" is required to print "-n -n hello".

echo -n is a GNU-ism that deviates from the spec.

> I remember this well because when I read it for the first time, there
> was a loop looking for -n, which prompted me to ask --- omg, how am I
> going to print ``-n'' to the terminal?

Without a newline?

printf %s -n

printf is not forbidden from taking options (though POSIX doesn't
describe any), so another way would require the use of -- so -n doesn't
look like an option.

printf -- -n

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <480-992-1380@kylheku.com> writes:
> On 2021-11-24, Meredith Montgomery <mmontgomery@levado.to> wrote:
>> This is odd. I had seen the echo.c from some BSD system in the past. I
>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>> was OpenBSD because OpenBSD's source still behaves I remember it.
>> Here's the behavior.
>>
>> %echo -n -n hello
>> hello%
>
> According to POSIX, echo doesn't take any options, including the --
> option to end options. See here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
>
> 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.
>
> Implementations shall not support any options.
>
> Thus, "echo -n -n hello" is required to print "-n -n hello".
>
> echo -n is a GNU-ism that deviates from the spec.

Do we know where the -n option originated? It exists in a number of
different implementations of echo, not just GNU. My guess is that GNU
wasn't the origin.

Note that there are at least two GNU implementations of echo, the echo
command provided by the coreutils package and the builtin echo command
provided by GNU bash.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>> On 2021-11-24, Meredith Montgomery <mmontgomery@levado.to> wrote:
>>> This is odd. I had seen the echo.c from some BSD system in the past. I
>>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>>> was OpenBSD because OpenBSD's source still behaves I remember it.
>>> Here's the behavior.
>>>
>>> %echo -n -n hello
>>> hello%
>>
>> According to POSIX, echo doesn't take any options, including the --
>> option to end options. See here:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
>>
>> 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.
>>
>> Implementations shall not support any options.
>>
>> Thus, "echo -n -n hello" is required to print "-n -n hello".
>>
>> echo -n is a GNU-ism that deviates from the spec.
>
> Do we know where the -n option originated? It exists in a number of
> different implementations of echo, not just GNU. My guess is that GNU
> wasn't the origin.
>
> Note that there are at least two GNU implementations of echo, the echo
> command provided by the coreutils package and the builtin echo command
> provided by GNU bash.
>
> [...]

I found some more information here:
https://en.wikipedia.org/wiki/Echo_(command)#History

echo began within Multics. After it was programmed in C by Doug
McIlroy as a "finger exercise" and proved to be useful, it became
part of Version 2 Unix. echo -n in Version 7 replaced prompt, (which
behaved like echo but without terminating its output with a line
delimiter).

On PWB/UNIX and later Unix System III, echo started expanding C
escape sequences such as \n with the notable difference that octal
escape sequences were expressed as \0ooo instead of \ooo in C.

Eighth Edition Unix echo only did the escape expansion when passed a
-e option, and that behaviour was copied by a few other
implementations such as the builtin echo command of Bash or zsh and
GNU echo.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>>> On 2021-11-24, Meredith Montgomery <mmontgomery@levado.to> wrote:
>>>> This is odd. I had seen the echo.c from some BSD system in the past. I
>>>> don't recall which it was --- OpenBSD, FreeBSD, NetBSD. But I think it
>>>> was OpenBSD because OpenBSD's source still behaves I remember it.
>>>> Here's the behavior.
>>>>
>>>> %echo -n -n hello
>>>> hello%
>>>
>>> According to POSIX, echo doesn't take any options, including the --
>>> option to end options. See here:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
>>>
>>> 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.
>>>
>>> Implementations shall not support any options.
>>>
>>> Thus, "echo -n -n hello" is required to print "-n -n hello".
>>>
>>> echo -n is a GNU-ism that deviates from the spec.
>>
>> Do we know where the -n option originated? It exists in a number of
>> different implementations of echo, not just GNU. My guess is that GNU
>> wasn't the origin.
>>
>> Note that there are at least two GNU implementations of echo, the echo
>> command provided by the coreutils package and the builtin echo command
>> provided by GNU bash.
>>
>> [...]
>
> I found some more information here:
> https://en.wikipedia.org/wiki/Echo_(command)#History

Nice. Thanks for sharing.

> echo began within Multics. After it was programmed in C by Doug
> McIlroy as a "finger exercise" and proved to be useful, it became
> part of Version 2 Unix. echo -n in Version 7 replaced prompt, (which
> behaved like echo but without terminating its output with a line
> delimiter).

The -n is a nice addition, I think.

> On PWB/UNIX and later Unix System III, echo started expanding C
> escape sequences such as \n with the notable difference that octal
> escape sequences were expressed as \0ooo instead of \ooo in C.

Now I think they should've changed the name. :-)

[...]

Kaz Kylheku wrote:

> According to POSIX, echo doesn't take any options, including the --
> option to end options. See here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
>
> 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.
>
> Implementations shall not support any options.
>
> Thus, "echo -n -n hello" is required to print "-n -n hello".

That doesn't follow. The requirement that echo does not support any
options, and that "--" is not special, just mean that all of the
arguments are required to be treated as operands. The echo OPERANDS
section in POSIX says this:

The following operands shall be supported:

string
A string to be written to standard output. If the first
operand is -n, or if any of the operands contain a <backslash>
character, the results are implementation-defined.

(It then goes on to specify XSI requirements that include treating
a first operand of -n as a string to be output, and special treatment
of backslash escapes.)

> echo -n is a GNU-ism that deviates from the spec.

No, it's allowed for non-XSI echo implementations.

However, "echo -- -n hello" is required to print "-- -n hello".

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> Note that there are at least two GNU implementations of echo, the echo
> command provided by the coreutils package and the builtin echo command
> provided by GNU bash.

Judging from comments in the code, the former is a GNU-internal fork of
the latter.