[Toybox] [PATCH] Fix more to a non-tty.

[enh]

On Sat, Apr 23, 2016 at 12:39 PM, Rob Landley <rob at landley.net> wrote:
> On 04/21/2016 07:42 PM, enh wrote:
>> And add a test.
>> ---
>>  toys/pending/more.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied, but I don't see the test?

d'oh. fooled by git commit -a yet again.

> Sigh: I wanted "more" and "less" to share code, but they really don't do
> the same thing (random example: "ls --color | more" vs "ls --color | less").

there's "less -r". but i didn't know that until i read the help just now :-)

having more(1) be the simplest possible thing probably best matches
the intentions of anyone who deliberately chooses more(1) over less(1)
anyway.

> I was vaguely going "yeah, but I need even MORE smarts than that to
> implement screen, and if less can share that code and parse ansi escape
> sequences the way screen needs to, then it can also act like more!" but
> just because I CAN do that doesn't mean I SHOULD. The point of "more" is
> to be fairly simple.
>
> So, cleaning up more, let's see:
>
>   FILE *fp, *cin;
>
>   if (!isatty(1) || !(cin = fopen("/dev/tty", "r"))) {
>     loopfiles(toys.optargs, do_cat_operation);
>     return;
>   }
>
>   TT.cin_fd = fileno(cin);
>
> If we know stdout is a tty, and we _REQUIRE_ stdout to be a tty, why are
> we opening /dev/tty? (Because stdout may be a _different_ tty than the
> one controlling stdin? Is that a real concern?)
>
> Yes, apparently! Ctrl-alt-f1, login as root (otherwise you can't write
> to terminals you don't own), more README > /dev/tty3, and the output
> goes there (as well as the prompts!) but the input
>
> That's INSANE. Can I read from stdout? (Did they open it write-only? I
> can almost always write to stdin...)
>
> Gee, wouldn't it be nice if posix covered ANY of this? Let's go read the
> posix more spec again...
>
>> If standard output is not a terminal device, all input files shall be
>> copied to standard output in their entirety, without modification,
>> except as specified for the -s option.
>
> Modulo inserting :::: headers between them?
>
>> If standard output is a terminal, standard error shall be used to
> ? read commands from the user. If standard output is a terminal,
>> standard error is not readable, and command input is needed, more may
>> attempt to obtain user commands from the controlling terminal (for
>> example, /dev/tty);
>
> So I can read from stderr? But I'm NOT to read from stdout, even when
> the above redirection exercise makes stdout the only place connected to
> the terminal the output is actually going to?
>
>> If standard output is not a terminal, no error shall result if
>> standard error cannot be opened for reading.
>
> How do you OPEN standard error? It's file descriptor 2! What, do you
> expect /dev/stderr or /proc/self/fd/2 to reliably exist and have
> meaning? That's portable? What are these people smoking?
>
> Sigh. Where does it define stdin/stdout/stderr? Hmmm...
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>
> Not it...
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/stderr.html
>
> Defers to the ISO C standard. Of course. It does hardwire STDIN_FILENO
> to 0 and so on, but doesn't say which are readable and writeable. I'm
> pretty sure shell redirection
> (file:///home/landley/reading/SUSv4/utilities/V3_chap02.html#tag_18_07)
> opening files "for reading" and "for writing" are limiting these...
>
> Meanwhile, another design question: is resetting the terminal to the
> current state (vs a known state) useful? In lib/interestingtimes.c I
> have set_terminal() which sets the terminal to either raw or cooked
> mode, but does so by setting all the flags a known state. (Because it's
> 2016, there haven't been 'terminal devices' in a while: the state
> "reset" puts the terminal into is the one it should probably be in when
> it's not in raw mode.)
>
> While it can save the old terminfo so you can put it back with
> tcsetattr(), the only user that actually _does_ that is read_password()
> in lib/passwd.c, which was grandfathered in submitted code and still not
> quite fully cleaned up.
>
> So the question is: would set_terminal(fd, raw) be reasonable, so you
> just set_terminal(1, 1) on the way in and set_terminal(1, 0) on the way
> out? In theory this can lose the previous terminal state, but I'm
> unaware of that causing a _problem_ these days?
>
> Dunno. It does have the advantage of encapsulating all the tty setting
> logic into one place, except that there's a THIRD state, which is "don't
> echo input back, but don't screw up output either". Where
>
> (You wonder why it takes me so long to clean stuff up? This is why. This
> is MAYBE the first 10% of the _research_ to do the cleanup...)
>
> Rob
>
> (There is no WAY I'm having a release ready tomorrow. Grrr. Let's see
> what I can get done on the plane...)
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.