[-- 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 --]
How would you wish to interact with /bin/bash >file Doug
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)
[-- 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 --]
[-- 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 --]
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 #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 --]
> 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 :^)
[-- 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 --]
[-- 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 --]
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)