-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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. |
Since I haven't seen this suggested before: how about returning |
…nce, r=thomcc kmc-solid: `std::sys` code maintenance Includes a set of changes to fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets and make some other improvements. - Address `fuzzy_provenance_casts` by using `expose_addr` and `from_exposed_addr` for pointer-integer casts - Add a stub implementation of `is_terminal` (rust-lang#98070) - Address `unused_imports` and `unused_unsafe` - Stop doing `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`
…nce, r=thomcc kmc-solid: `std::sys` code maintenance Includes a set of changes to fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets and make some other improvements. - Address `fuzzy_provenance_casts` by using `expose_addr` and `from_exposed_addr` for pointer-integer casts - Add a stub implementation of `is_terminal` (rust-lang#98070) - Address `unused_imports` and `unused_unsafe` - Stop doing `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`
…nce, r=thomcc kmc-solid: `std::sys` code maintenance Includes a set of changes to fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets and make some other improvements. - Address `fuzzy_provenance_casts` by using `expose_addr` and `from_exposed_addr` for pointer-integer casts - Add a stub implementation of `is_terminal` (rust-lang#98070) - Address `unused_imports` and `unused_unsafe` - Stop doing `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`
Refs: - softprops/atty#57 - clap-rs/clap#4249 - rustsec/advisory-db#1457 - rust-lang/rust#98070 Signed-off-by: Konstantin Shabanov <mail@etehtsea.me>
…nce, r=thomcc kmc-solid: `std::sys` code maintenance Includes a set of changes to fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets and make some other improvements. - Address `fuzzy_provenance_casts` by using `expose_addr` and `from_exposed_addr` for pointer-integer casts - Add a stub implementation of `is_terminal` (rust-lang#98070) - Address `unused_imports` and `unused_unsafe` - Stop doing `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`
@BurntSushi I've posted #109687 to add the heuristics to the documentation. Sorry for the delay in doing so. |
I'd like to propose stabilizing this. I'd like to find out if we have consensus in doing so. @rfcbot merge |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
I don't quite agree with this. While it's true this can safely be added to std, I don't see why it should be. It has lived fine in crates and I'm not able to think of any problems that are solved by bringing it in std |
I don't agree with it being fine in other crates. |
There is also a desire to use this in |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
…, r=Mark-Simulacrum Stabilize IsTerminal FCP completed in rust-lang#98070 . closes: rust-lang#98070
…, r=Mark-Simulacrum Stabilize IsTerminal FCP completed in rust-lang#98070 . closes: rust-lang#98070
…, r=Mark-Simulacrum Stabilize IsTerminal FCP completed in rust-lang#98070 . closes: rust-lang#98070
…Simulacrum Stabilize IsTerminal FCP completed in rust-lang/rust#98070 . closes: rust-lang/rust#98070
…Simulacrum Stabilize IsTerminal FCP completed in rust-lang/rust#98070 . closes: rust-lang/rust#98070
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: