New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for IsTerminal / is_terminal #98070
Comments
Not a strong objection, but I wonder if there has been any discussion about making this universally available vs. it being a OS-specific |
@nagisa I've updated the API (and now the documentation in this tracking issue): it now just returns I personally think that there's value in being able to call it universally and just get a "false", because "treat as a non-terminal" is almost always the correct behavior in such cases: don't try to do fancy formatting, don't try to invoke a pager, don't do progress bars, just output text. |
I don't feel strongly here either I think, but an alternative and perhaps slightly more idiosyncratic API would be On the other hand, it might be just as interesting to report why So maybe just a |
This is a nice addition to std! But... oof, that return value. Combining It's trivial for the caller to write (As to the error type, I'd say any |
I'm not sure if this has been discussed, but I'm actually surprised that this is in Out of curiosity, what's the impetus for experiment with standardizing this functionality in |
@BurntSushi @kwi-dk I originally wrote this to return an error, but it turns out in practice that there aren't any interesting error cases on existing platforms. For instance, on UNIX, apart from "success, this is a terminal" or "this is not a terminal", the only error is "you passed something that isn't a file descriptor", and that isn't a useful case for any of the types you can call |
@joshtriplett For Unix, yeah, I probably agree. All of the interesting error cases would be on the Windows side. And there is the question of not just "did a syscall fail somewhere" but also "why is it thought that this is a terminal" and "why is it thought that this is not a terminal." |
@BurntSushi I don't think in practice "why is it thought that this is a terminal" has a very useful answer. And if you're looking for Windows-specific info like "did this have one of the magic names", that seems like something we shouldn't expose in any stable fashion, because eventually we hope it'll go away. |
@ErichDonGubler There are multiple crates providing this functionality, such as I don't think this is a change from historical precedent. We're not going to add GUIs or XML parsers to the standard library. The general reaction to this change from users of atty has, in general, seemed to be various degrees of elation. |
I'm not advocating (or even suggesting hypothetically) that we expose "did this have one of the magic names" in any stable fashion. :-) I'm not quite sure where the disconnect is here. I'll try again. Broadly, I have two points to bring up. The first point are the docs. Today, the docs don't mention that heuristics may be used in determining whether something is attached to a terminal or not. I think we should mention that, even if we hope that the heuristics used on Windows will one day go away. (Looking for those magic names is the heuristic I'm thinking about specifically.) The second point is that because we use heuristics (and I don't see those going away any time soon), the Thus, it could be sensible to return something richer than just a To be clear, for my second point above, I am not saying "this is definitely what we should do." But rather, "it is perhaps something we should consider." I am myself not convinced that the extra ceremony is worth the improvement in failure modes, but it could be. It is perhaps possible that I feel this a little more strongly because, in the course of adding the heuristic to It is plausible that the heuristic is good enough that it simply will almost never do something unexpected. In which case, the value of better failure modes decreases. To be doubly clear, I would rather have this API return a |
I misunderstood, thank you for clarifying.
I completely agree that the documentation should explain the details of the heuristics.
I personally think that attempting to return an error indicating the reason for a I feel like that's a really good argument for having a debug version of the standard library where it's possible to enable all sorts of tracing via environment variables. |
Right, and I realize now that that would require unsoundness. So barring kernel bugs or OS-level shenanigans (like LD_PRELOAD, ptrace or seccomp-bpf, which are all out of scope in the same manner as On Windows I can certainly manufacture odd situations where a console handle has only What quibbles remain then comes down to documentation. I withdraw my concern, and look forward to using this in my CLI tools. |
joshtriplett commentedJun 13, 2022
•
edited
Feature gate:
#![feature(is_terminal)]
This is a tracking issue for the
IsTerminal
trait and itsis_terminal
method, to determine if a descriptor/handle refers to a terminal.Public API
Steps / History
IsTerminal
trait to determine if a descriptor or handle is a terminal #98033The text was updated successfully, but these errors were encountered: