nixers
A digression on echo. - Printable Version
+- nixers (https://nixers.net)
+-- Forum: Operating Systems & Administration (https://nixers.net/Forum-Operating-Systems-Administration)
+--- Forum: Other *nix-like OSes & POSIX related (https://nixers.net/Forum-Other-nix-like-OSes-POSIX-related)
+--- Thread: A digression on echo. (/Thread-A-digression-on-echo--2311)

A digression on echo. - seninha - 20-04-2020

After commenting on this thread I remembered a text on echo that Brian Kernighan and Rob Pike wrote in their book The UNIX Programming Environment called A digression on echo.

[Image: j5kXsXV.png]

The single option -n is not like other options in other utilities.
For example, while most utilities use getopt(3) to get the options, echo(1) should not use it, since a gotten option could be an argument to be echoed. See how OpenBSD implement echo, for example:

Code:
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <err.h>

/* ARGSUSED */
int
main(int argc, char *argv[])
{
    int nflag;

    if (pledge("stdio", NULL) == -1)
        err(1, "pledge");

    /* This utility may NOT do getopt(3) option parsing. */
    if (*++argv && !strcmp(*argv, "-n")) {
        ++argv;
        nflag = 1;
    }
    else
        nflag = 0;

    while (*argv) {
        (void)fputs(*argv, stdout);
        if (*++argv)
            putchar(' ');
    }
    if (!nflag)
        putchar('\n');

    return 0;
}

Other than -n, modern echo implementations also add a new complexity: the C-like backslash sequences like '\n' and '\t'. Some echo implementations (such as OpenBSD's) just ignore them, but some (such as Bash built-in) don't. Here is another digression on echo about this very topic, by Doug Mcllroy, best known for proposing the UNIX pipelines and creating several UNIX tools:

[Image: gFPe9sR.png]

There is, however, another utility that does not print newlines when not asked for and that does interpret C-like backslash sequences: printf(1)

PS: I don't know the right forum to post it. I posted it here in the Philosophy forum since I think that the question on bloatedness and feature creep are related to UNIX Philosophy.

RE: A digression on echo. - jkl - 20-04-2020

This seems to be one of the better examples on how Unix defaults to non-predictive behavior sometimes.

RE: A digression on echo. - z3bra - 20-04-2020

Good job digging up the history behind it. it was a really interesting read !

Reading the source code for echo under different implementations has been an exercise many people have taken to compare code complexity (obviously, GNU "wins" here).

I personally only use "echo" to print out debug statements, or quickly output a variable name. For example, all my scripts feature this snippet:

Code:
usage() {
    echo "usage: $(basename $0) [-flags] args..." >&2
}

Whenever I need to print out formatted stuff, printf(1) is my goto as it is much more convenient.

RE: A digression on echo. - seninha - 20-04-2020

(20-04-2020, 03:40 PM)z3bra Wrote: Reading the source code for echo under different implementations has been an exercise many people have taken to compare code complexity (obviously, GNU "wins" here).

This comparison remembered me of this meme, based on longcat.

[Image: 7r5Q1qA.png]


RE: A digression on echo. - jkl - 20-04-2020

I wonder how much of the GNU code is a try to circumvent the limitations imposed by its libc compared to Plan 9’s.

RE: A digression on echo. - z3bra - 21-04-2020

Hahaha awesome meme !

(20-04-2020, 04:33 PM)jkl Wrote: I wonder how much of the GNU code is a try to circumvent the limitations imposed by its libc compared to Plan 9’s.

I think they're more trying to circumvent their own coding guidelines than the libc… Which is even more terrifying if you ask me. I mean. what the hell is this? or that? I'm speechless…

RE: A digression on echo. - jkl - 21-04-2020

"GNU's Not Unix. And here's how we mean that."

RE: A digression on echo. - twee - 21-04-2020

Reading the GNU coding standards was what convinced me to move back to OpenBSD, after having had to move back to Linux for certain software support which is no longer an issue. In particular, this paragraph:

Quote: For instance, Standard C says that nearly all extensions to C are
prohibited. How silly! GCC implements many extensions, some of which
were later adopted as part of the standard. If you want these
constructs to give an error message as "required" by the standard, you
must specify '--pedantic', which was implemented only so that we can say
"GCC is a 100% implementation of the standard", not because there is any
reason to actually use it.

It reads to me both as quite immature and as something of a "Microsoftian" attitude. Every time I see GNU code I find it offputting, and I wouldn't even really consider myself a UNIX purist.

RE: A digression on echo. - seninha - 28-11-2020

Another GNUism that turned out into a meme:
GNU true(1), an utility that is supposed to return zero (true), can return non-zero (false).
That's because it does way more than return 0.

Compare OpenBSD implementation of true(1) with GNU's.

Code:
/*    $OpenBSD: true.c,v 1.1 2015/11/11 19:05:28 deraadt Exp $    */

/* Public domain - Theo de Raadt */

int
main(int argc, char *argv[])
{
    return (0);
}

Code:
/* Exit with a status code indicating success.
   Copyright (C) 1999-2020 Free Software Foundation, Inc.

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */

#include <config.h>
#include <stdio.h>
#include <sys/types.h>
#include "system.h"

/* Act like "true" by default; false.c overrides this.  */
#ifndef EXIT_STATUS
# define EXIT_STATUS EXIT_SUCCESS
#endif

#if EXIT_STATUS == EXIT_SUCCESS
# define PROGRAM_NAME "true"
#else
# define PROGRAM_NAME "false"
#endif

#define AUTHORS proper_name ("Jim Meyering")

void
usage (int status)
{
  printf (_("\
Usage: %s [ignored command line arguments]\n\
  or:  %s OPTION\n\
"),
          program_name, program_name);
  printf ("%s\n\n",
          _(EXIT_STATUS == EXIT_SUCCESS
            ? N_("Exit with a status code indicating success.")
            : N_("Exit with a status code indicating failure.")));
  fputs (HELP_OPTION_DESCRIPTION, stdout);
  fputs (VERSION_OPTION_DESCRIPTION, stdout);
  printf (USAGE_BUILTIN_WARNING, PROGRAM_NAME);
  emit_ancillary_info (PROGRAM_NAME);
  exit (status);
}

int
main (int argc, char **argv)
{
  /* Recognize --help or --version only if it's the only command-line
     argument.  */
  if (argc == 2)
    {
      initialize_main (&argc, &argv);
      set_program_name (argv[0]);
      setlocale (LC_ALL, "");
      bindtextdomain (PACKAGE, LOCALEDIR);
      textdomain (PACKAGE);

      /* Note true(1) will return EXIT_FAILURE in the
         edge case where writes fail with GNU specific options.  */
      atexit (close_stdout);

      if (STREQ (argv[1], "--help"))
        usage (EXIT_STATUS);

      if (STREQ (argv[1], "--version"))
        version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
                     (char *) NULL);
    }

  return EXIT_STATUS;
}