Re: [TUHS] Why does shell write to stderr?

Re: [TUHS] Why does shell write to stderr?

[Douglas McIlroy]

How would you wish to interact with
        /bin/bash >file

Doug

Re: [TUHS] Why does shell write to stderr?

[Steffen Nurpmeso]

Douglas McIlroy wrote in
 <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>:
 |How would you wish to interact with
 |        /bin/bash >file

While the POSIX standard defines an interactive shell as one with
STDIN and STDERR being a terminal, i think the NetBSD shell did
not until not too long (< half a decade?) ago, and the mailer you
were using for a long time does not to this day.  (Unfortunately.)

  APPLICATION USAGE
  Standard input and standard error are the files that determine
  whether a shell is interactive when -i is not specified. For
  example:

    sh > file
  and:
    sh 2> file

  create interactive and non-interactive shells,
  respectively. Although both accept terminal input, the results of
  error conditions are different, as described in Section 2.8.1 (on
  page 2363); in the second example a redirection error encountered
  by a special built-in utility aborts the shell.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] Why does shell write to stderr?

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> How would you wish to interact with
>         /bin/bash >file
>

I am not sure. I could see the argument either way right now.


On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> How would you wish to interact with
>         /bin/bash >file
>
> Doug
>

[-- Attachment #2: Type: text/html, Size: 984 bytes --]

Re: [TUHS] Why does shell write to stderr?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

I am indeed a throwback but programs calling stat or stty to examine their
I/O state before deciding how to behave was a shock when I first saw it
done, in Berkeley ls I think, and still feels misguided. I understand the
convenience but not every convenience is good engineering.

-rob


On Fri, Apr 8, 2022 at 7:38 AM Richard Salz <rich.salz@gmail.com> wrote:

> On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
>
>> How would you wish to interact with
>>         /bin/bash >file
>>
>
> I am not sure. I could see the argument either way right now.
>
>
> On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
>
>> How would you wish to interact with
>>         /bin/bash >file
>>
>> Doug
>>
>

[-- Attachment #2: Type: text/html, Size: 1695 bytes --]

Re: [TUHS] Why does shell write to stderr?

[George Michaelson]

I also had extreme WTF the first time I looked in code and saw an
isatty() guard over some activity.

"this program processes stdin to stdout, except.. if I decide
otherwise" never appeared in man pages.

But that said, it sort of made sense. Why ring bell in an editor, if
you know the input pipe side can't hear it? A tty is a rather strange
device being the join over stdout, stdin and stderr, and there is a
(tiny?) set of things which need to know.

more for instance, probably needs to know that waiting for a command
to move pagination onward if there is no controlling terminal is not
sensible. If you want your input in chunks, more is not the way to do
it.

I hate special cases. This is why people say english is so hard to
learn but really all languages have them, its just that english having
stolen words from everywhere has more instances of isatty() than
others.

-G

Re: [TUHS] Why does shell write to stderr?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

If you never ring the bell in the editor, the issue never comes up, the
code is simpler, and there's less to understand.

-rob


On Fri, Apr 8, 2022 at 8:33 AM George Michaelson <ggm@algebras.org> wrote:

> I also had extreme WTF the first time I looked in code and saw an
> isatty() guard over some activity.
>
> "this program processes stdin to stdout, except.. if I decide
> otherwise" never appeared in man pages.
>
> But that said, it sort of made sense. Why ring bell in an editor, if
> you know the input pipe side can't hear it? A tty is a rather strange
> device being the join over stdout, stdin and stderr, and there is a
> (tiny?) set of things which need to know.
>
> more for instance, probably needs to know that waiting for a command
> to move pagination onward if there is no controlling terminal is not
> sensible. If you want your input in chunks, more is not the way to do
> it.
>
> I hate special cases. This is why people say english is so hard to
> learn but really all languages have them, its just that english having
> stolen words from everywhere has more instances of isatty() than
> others.
>
> -G
>

[-- Attachment #2: Type: text/html, Size: 1530 bytes --]

Re: [TUHS] Why does shell write to stderr?

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Thu, Apr 7, 2022 at 7:53 PM Rob Pike <robpike@gmail.com> wrote:

If you never ring the bell in the editor, the issue never comes up, the
> code is simpler, and there's less to understand.
>

Well, yes.  And by the same token, you can eliminate the complexities of
i18n by having only one diagnostic, namely "?" (or by pretending all the
world is anglophone).

But setting aside for the moment this style of argumentation, let's
consider directory colorization.  I have no dog in this fight, as I set all
my terminals to black-on-white as God and Gutenberg intended, and set TERM
to vt100 so the colors can't be changed.  However, the feature seems to be
extremely popular, and can't be readily done outboard in a pipeline],
unlike most of the infamous options of cat(1).  As things stand, the X3.64
control sequences output by colorization are *not* suppressed when the
output of ls isn't a terminal, which means I have had to write a stripper
for them.  Another example is cal(1), which tries to output the current day
in reverse video, which is equally annoying but fortunately can be
suppressed more easily by piping it through more(1).

[-- Attachment #2: Type: text/html, Size: 2064 bytes --]

Re: [TUHS] Why does shell write to stderr?

[George Michaelson]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

>
> Kinda think you're running Rob's argument for him by inductive reasoning.

If those other progroids read env() they could learn if colour was du Jure
or not. No isatty() required.

I think there always will be some special cases and like cardamom pods in
curry you hate them when you bite them.

G

>
>

[-- Attachment #2: Type: text/html, Size: 1132 bytes --]

Re: [TUHS] Why does shell write to stderr?

[Steffen Nurpmeso]

John Cowan wrote in
 <CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>:
 |On Thu, Apr 7, 2022 at 7:53 PM Rob Pike <robpike@gmail.com> wrote:
 |If you never ring the bell in the editor, the issue never comes up, the
 |> code is simpler, and there's less to understand.
 |
 |Well, yes.  And by the same token, you can eliminate the complexities of
 |i18n by having only one diagnostic, namely "?" (or by pretending all the
 |world is anglophone).
 |
 |But setting aside for the moment this style of argumentation, let's
 |consider directory colorization.  I have no dog in this fight, as I set all
 |my terminals to black-on-white as God and Gutenberg intended, and set TERM

Johannes Gutenberg?  The bible was in parts red-on-white at least,
and had beautiful coloured paintings, too.  (They did not know
about the communist Charlie Chaplin and his Modern Times by then.)

  ...

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] Why does shell write to stderr?

[Paul Ruizendaal via TUHS]

> If you never ring the bell in the editor, the issue never comes up

As natural language ambiguity was brought up: it makes the code less noisy :^)

[TUHS] Why does shell write to stderr?

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Looking at
https://unix.stackexchange.com/questions/380012/why-does-bash-interactive-shell-by-default-write-its-prompt-and-echoes-its-inter,
in particular the first answer which has a link to
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main%E2%80%8C%E2%80%8B.c
Made me wonder: why?

[-- Attachment #2: Type: text/html, Size: 596 bytes --]