Fix Re-enabling manual Style creation

[mhelsley]

Fixes #46 by moving OSControl out of Style and into AnsiGenericString

[mhelsley]

@fdncred To save you time spent reviewing: Added another commit which introduces test code for detecting similar breaking changes in the future.

[fdncred]

I'm trying to test the examples. Here's my results.

CWD

And while it's waiting, I start a new terminal window, which I think is supposed to start in the for_cwd folder, but it doesn't. Maybe I'm misunderstanding what cwd is supposed to do.

Hyperlink

Hyperlink doesn't look right either, but when I click on the hyperlink it goes to example.com

icon

icon may just not work in Windows Terminal (not sure if it's supported) but it does change like this. the printout looks wrong as in the others.

title

seems to be working, except for what it's printing out

[fdncred]

It's the \x01 an \x02 that are messing things up on Windows. I removed them and here are the results for hyperlink.

I ran all the examples and the output on the screen looked right. I'm still not sure how to see what cwd does.

[mhelsley]

It's the \x01 an \x02 that are messing things up on Windows. I removed them and here are the results for hyperlink.

Oh, interesting. OK, I'll remove them from each one then.

Can you try putting a hyperlink in your command prompt? (e.g. setting one in PS1 in bash)
The reason I put those in is bash and readline use them to determine the invisible portions of the prompt so it knows how long the prompt is visually and can avoid clobbering the prompt and uses the full number of columns available when editting, choosing history, etc.

I ran all the examples and the output on the screen looked right. I'm still not sure how to see what cwd does.

If you've got a Mac try running it in Terminal.app and, while it's waiting 5 seconds, try opening a new window (it's been a while since I've used Terminal.app since I no longer have a Mac -- if there's a way to do it that's associated with that original window then that's the way you want to try). It should open the new terminal window in the ${PWD}/for_cwd/ directory rather than the ${PWD} directory you're running the example from (e.g. the top directory of the repo).

[fdncred]

Can you try putting a hyperlink in your command prompt? (e.g. setting one in PS1 in bash)

This would take some work. I'd have to compile nushell with this PR, write a nushell command to respond to your new hyperlink command, and call it from my script. Is there maybe an easier way to do this? Maybe I can just tweak the example and call it?

If you've got a Mac try running it in Terminal.app and, while it's waiting 5 seconds, try opening a new window (it's been a while since I've used Terminal.app since I no longer have a Mac -- if there's a way to do it that's associated with that original window then that's the way you want to try). It should open the new terminal window in the ${PWD}/for_cwd/ directory rather than the ${PWD} directory you're running the example from (e.g. the top directory of the repo).

I tried iterm2, wezterm, and terminal.app and couldn't get any of them to respond properly to cwd

[fdncred]

I put it in the right prompt and it looks like this on Windows 11 with Windows Terminal

Tabby Windows

WezTerm Windows

Alacritty Windows

iterm2 Mac

WezTerm Mac

Alacritty Mac

Terminal.app Mac

[mhelsley]

Can you try putting a hyperlink in your command prompt? (e.g. setting one in PS1 in bash)

This would take some work. I'd have to compile nushell with this PR, write a nushell command to respond to your new hyperlink command, and call it from my script. Is there maybe an easier way to do this? Maybe I can just tweak the example and call it?

You could modify the hyperlink example to only output the hyperlink (no other content in the format string) and not sleep.

Then, at least in a new bash shell (e.g. run bash from within your current nushell) you could do:

unset PROMPT_COMMAND
PS1=$(./example/hyperlink)

If you want to manually write the hyperlinks without nu-ansi-term here's how to try two variations. For the variation with the \0x01 ... \x02 wrapper (which prevents command line editing/history navigation errors in bash at least):

unset PROMPT_COMMAND
PS1=$(echo -e '\\[\e]8;;https://example.com\e\\\\\]link example\\[\e]8;;\e\\\\\\] $ ')

Without the \0x01 ... \x02 wrapper (should create weird problems modifying command lines, navigating history with up-arrow, etc.):

unset PROMPT_COMMAND
PS1=$(echo -e '\e]8;;https://example.com\e\\\\link example\e]8;;\e\\\\ $ ')

and that will put a hyperlink in your prompt. I don't know how to make nushell invoke a program to get prompt content but that's essentially what you're looking for.

If you've got a Mac try running it in Terminal.app and, while it's waiting 5 seconds, try opening a new window (it's been a while since I've used Terminal.app since I no longer have a Mac -- if there's a way to do it that's associated with that original window then that's the way you want to try). It should open the new terminal window in the ${PWD}/for_cwd/ directory rather than the ${PWD} directory you're running the example from (e.g. the top directory of the repo).

I tried iterm2, wezterm, and terminal.app and couldn't get any of them to respond properly to cwd

Odd. Well, maybe I ought to remove ::cwd() since we can't find a single terminal that seems to do anything with it.

[mhelsley]

I put it in the right prompt and it looks like this on Windows 11 with Windows Terminal

Looks like this is the only one so far that doesn't like the \x01 ... \x02 sequences.

[mhelsley]

vtparse is the package I've been working on which could help test all kinds of Color, Style, and OSControl pieces while working within a lightweight CI pipeline.

[fdncred]

I think we should remove the \x01 and \x02 as the default way to do this but document it somehow for people that need it. If people want to use is they can add the SOH/STX manually.

Another option is to add a parameter to the function or a separate function to add the SOH/STX bookends.

[mhelsley]

I think we should remove the \x01 and \x02 as the default way to do this but document it somehow for people that need it. If people want to use is they can add the SOH/STX manually.

For most the OSC sequences this works well. However with the hyperlink they can't just wrap the whole string in \x01 ... \x02. They have to wrap not just the link target portion but only the escape sequences (ESC ST and then OSC 8 ;; ESC ST) on either side of the displayed text in the "middle" of the AnsiGenericString. At that point, if outputting hyperlinks is the main reason they chose it, what effort is using nu-ansi-term saving them?

Another option is to add a parameter to the function or a separate function to add the SOH/STX bookends.

I think this makes more sense -- at least for the hyperlink. The separate function to turn it on for all escape sequences could be useful in packages that use nu-ansi-term. I can think of part of Statship specifically, at least, where it could replace a somewhat elaborate function that does add these wrappers around the escape sequences. which adds some string-copying work. I'll look into both options.

On the testing side of things how are you feeling about the test code as it stands? Are the examples running in CI going to be enough or is more needed?

[fdncred]

testing

I love the examples and don't mind running them manually from time to time. i haven't tried running them in ci. however, i've not been able to make cwd work at all.

SOH/STX

Ok, I'm good with another param or separate function. I'll let you decide which is best.

[mhelsley]

Almost there. Pushed some changes so you can see, in a separate commit rather than with the fix, the "wrapping" code.

I do need to check the ESC ST sequence because I think there's something I'm not quite understanding there. If I don't output two \\\\ when it's in the output of a PROMPT_COMMAND in bash then there are spurious [ characters and command line editing is somehow worse.

I've also played with wrapping all of the SGR sequences. The code is much more complicated, though, and I think that would have to be a separate PR.

There's a TODO REVIEW in "Add optional OSC test combinatorial run" which I could use some help with; I don't know what the command line needs to be for Windows Terminal, WezTerm, etc. -- basically the non-Linux ones. I don't want to leave it as a TODO if I can avoid it.

[fdncred]

"Add optional OSC test combinatorial run"

I took the #[ignore] off the tests and tried to run them and they all passed. I'm not sure how since I don't have all those terminals on my mac. Maybe I'm just using the wrong command. I tried cargo test osc and cargo test --all-features.

The rest is looking good.

[mhelsley]

Running the (Ignored) Combinatorial Tests

"Add optional OSC test combinatorial run"

I took the #[ignore] off the tests and tried to run them and they all passed. I'm not sure how since I don't have all those terminals on my mac. Maybe I'm just using the wrong command.

Because it doesn't consider absence of the terminal to be a failure. That said, "success" doesn't seem like the right response either. I looked into how to report a "skip" at runtime and everything I've seen suggests there's no real way to do so via test summary output -- either it's statically ignored, filtered out by the command line, or it produces a pass/fail result.

So I modified the test to print useful output using eprintln!(). It will indicate whether the terminal is "Missing" or "Platform cannot run". However, unlike the default summary, to see the useful output you have to run the tests:

$ cargo test -- --ignored --show-output
...
$ cargo test --all-features -- --ignored --show-output
...

Of course, since it tries to run GUI terminals, that's not useful to put that in the CI runs. But if you've got Terminal.exe or Terminal.app it should open a new one for each OSC function. If it doesn't then the code for launching those commands isn't right and that's why it's still got the REVIEW comment there.

Note: For some reason cargo test is no longer letting me run only the OSC tests in tests/osc.rs -- no matter what I do it just ignores them when I try variations of cargo test osc .... I've given up trying to discern why since the --ignored flag does effectively the same thing at the moment.

Combinatorial Test Reorganization

I've reorganized the combinatorial test code. Now there will be one test ok/fail output per combination of OSC function to test and terminal to try. This more accurately reflects what's going on rather that hiding them by looping in run_combos(). It was useful because it could help me see that gnome-terminal wasn't being run even though I have it. So that's fixed too. The test functions will now show up in the summary as, for example, hyperlink::XTerm().

Dropping the Wrapping Stuff

Lastly, and most importantly, I figured out the issue I was seeing with needing to output two \ for ST. In prompt strings it needs to be escaped in addition to the 0x01 ... 0x02 wrapping. Seeing as that adds a whole other wrinkle on top of the wrapping bits, I'd still need to modify Starship to do that, etc. I finally realized: the wrapping code is an added feature which probably still needs some work. As such, rather than rolling it into a fix it should be a separate PR -- possibly including some handy escaping bits -- rather than delay this. So I moved it to my personal wrap-all branch. I think this is the right move but if you disagree I can bring it back for this PR.

[fdncred]

drop the wrapping

I think that's a good call

testing

I was wondering why Terminal.app was failing on my Mac. I found out that it's because the path is wrong. I'm not sure if this has changed in MacOS or it's just a M1 and later change? This is the new path.

/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

But it just hangs now and no terminal.app is shown. Not sure what's going on exactly.

Oh, this is interesting. I get this.

running 24 tests
test cwd::ETerm ... ok
test cwd::GnomeTerminal ... ok
test cwd::TerminalExe ... ok
test cwd::Rxvt ... ok
test hyperlink::ETerm ... ok
test hyperlink::GnomeTerminal ... ok
test hyperlink::Rxvt ... ok
test cwd::XTerm ... ok
test hyperlink::TerminalExe ... ok
test hyperlink::XTerm ... ok
test icon::GnomeTerminal ... ok
test icon::ETerm ... ok
test icon::Rxvt ... ok
test icon::TerminalExe ... ok
test icon::XTerm ... ok
test title::GnomeTerminal ... ok
test title::ETerm ... ok
test title::Rxvt ... ok
test title::TerminalExe ... ok
test title::XTerm ... ok
test cwd::TerminalApp has been running for over 60 seconds
test hyperlink::TerminalApp has been running for over 60 seconds
test icon::TerminalApp has been running for over 60 seconds
test title::TerminalApp has been running for over 60 seconds

But if i do a ps in another window, I see this

46791 ttys000    0:00.08 /Users/fdncred/.rustup/toolchains/stable-aarch64-apple-darwin/bin/cargo test -- --ignored --show-output
46835 ttys000    0:00.01 /Users/fdncred/src/nu-ansi-term/target/debug/deps/osc-98ace87dd48bab95 --ignored --show-output
46836 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]7;./for_cwd/^[\
46837 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[[4;34m^[]8;;https://example.com^[\Link to example.com^[]8;
46838 ttys000    0:00.09 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]I;./foo.icn^[\
46839 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]2;My Title^[\

I just never see the window. I have to killall Terminal to get the test to return at all.

cargo test osc

it runs fine here

cargo test osc                                                ✘ 101   3m 36s   1.70.0  08:12:01 AM
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests src/lib.rs (target/debug/deps/nu_ansi_term-7bfff3812bd5bd6a)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 70 filtered out; finished in 0.00s

     Running tests/osc.rs (target/debug/deps/osc-98ace87dd48bab95)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 24 filtered out; finished in 0.00s

     Running tests/style.rs (target/debug/deps/style-f5c8995a6b4cb12f)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s

[mhelsley]

I was wondering why Terminal.app was failing on my Mac. I found out that it's because the path is wrong. I'm not sure if this has changed in MacOS or it's just a M1 and later change? This is the new path.

/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

OK, I've replaced the path in my local tree. However in light of the rest of your reply I've kept digging.

But it just hangs now and no terminal.app is shown. Not sure what's going on exactly.

Oh, this is interesting. I get this.

running 24 tests
...
test cwd::TerminalApp has been running for over 60 seconds
test hyperlink::TerminalApp has been running for over 60 seconds
test icon::TerminalApp has been running for over 60 seconds
test title::TerminalApp has been running for over 60 seconds

Interesting. I didn't see any command line arguments that could be supplied to potentially fix that. However I've found another reference which may be potentially better or even fix your issue with the terminals not showing up. By any chance does:

open -n -F -W -a "/Applications/Utilities/Terminal.app" --args /usr/bin/sleep 10

open a terminal? The -W flag says to wait for the command to complete and, since it should be running sleep 10 it should finish waiting in 10 seconds so hopefully you won't see the same problem with lingering processes. The -a flag looks like it's supposed to supply a path to a .app in the /Applications directory however you could also try it with /System/ prepended if that fails.

How about:

open -n -F -W -b "com.apple.terminal" --args /usr/bin/sleep 10

This one replaces a path to the application with what I believe is a "bundle" reference of some kind.

But if i do a ps in another window, I see this

46791 ttys000    0:00.08 /Users/fdncred/.rustup/toolchains/stable-aarch64-apple-darwin/bin/cargo test -- --ignored --show-output
46835 ttys000    0:00.01 /Users/fdncred/src/nu-ansi-term/target/debug/deps/osc-98ace87dd48bab95 --ignored --show-output
46836 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]7;./for_cwd/^[\
46837 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[[4;34m^[]8;;https://example.com^[\Link to example.com^[]8;
46838 ttys000    0:00.09 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]I;./foo.icn^[\
46839 ttys000    0:00.08 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal  ^[]2;My Title^[\

I just never see the window. I have to killall Terminal to get the test to return at all.

I'm guessing the Terminal.app is open in the foreground when you run the tests, but if not then perhaps bringing it to the foreground or looking at its window list (in the menu bar if I recall) will show them / let you make them visible.

It's supposed to wait for the terminals to close. Without that you'd never see the test output because it'd just open, run, complete, and close too quickly to see. That happened with a bunch of terminals on my machine and there wasn't even a perceptible flicker of a briefly-open terminal window (and my machine, especially my graphics card, is somewhat old at this point).

cargo test osc

it runs fine here

cargo test osc                                                ✘ 101   3m 36s   1.70.0  08:12:01 AM
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests src/lib.rs (target/debug/deps/nu_ansi_term-7bfff3812bd5bd6a)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 70 filtered out; finished in 0.00s

While I expected to see 70 filtered out here because these are the non-osc tests...

 Running tests/osc.rs (target/debug/deps/osc-98ace87dd48bab95)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 24 filtered out; finished in 0.00s

It also filtered out the 24 osc tests here. That's the source of my confusion. Perhaps every #[test]-attributed function needs to be prefixed by the string osc for it to recognize them? Or maybe they have to be directly under the osc crate/module -- they can't be in their own mod?

[fdncred]

open

This is what I get.

❯ ^open -n -F -W -a "/Applications/Utilities/Terminal.app" --args /usr/bin/sleep 10
The application /Applications/Utilities/Terminal.app cannot be opened for an unexpected reason, error=Error Domain=NSCocoaErrorDomain Code=260 "The file “Terminal.app” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///Applications/Utilities/Terminal.app, NSFilePath=/Applications/Utilities/Terminal.app, NSUnderlyingError=0x6000022c18f0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

but using this launches a terminal but i can't tell that the --args command does anything because the terminal just remains open.
❯ ^open -n -F -W -a "/System/Applications/Utilities/Terminal.app" --args /usr/bin/sleep 10

open -n -F -W -b "com.apple.terminal" --args /usr/bin/sleep 10

This works but leaves the terminal open.

I'm guessing the Terminal.app is open in the foreground when you run the tests,

They were 4 terminal.apps open in my dock (which was hidden). Good guess. If i go to them and exit and quit the app, the tests will proceed. However I can't tell that it's doing anything. i.e. the title isn't changed, there's no hyperlink, cwd doesn't seem to work, don't notice any icon. I'm know cwd works in terminal.app because I implemented it in nushell. So does the title. Not sure about icon. I don't think hyperlink works at all. We have a command in nushell called ansi link and I can't activate or see any link in terminal.app.

[mhelsley]

They were 4 terminal.apps open in my dock (which was hidden). Good guess. If i go to them and exit and quit the app, the tests will proceed.

Yeah, that seems to be normal. As best I can tell cargo runs a limited number of test cases in parallel (seems to be about 4-6 -- perhaps some proportion of the number of CPUs). The test isn't supposed to finish until all the windows are closed because that ensures you get a chance to see the displayed terminal. So it makes sense that it wouldn't finish until all the new windows are closed.

However I can't tell that it's doing anything. i.e. the title isn't changed, there's no hyperlink, cwd doesn't seem to work, don't notice any icon. I'm know cwd works in terminal.app because I implemented it in nushell. So does the title. Not sure about icon. I don't think hyperlink works at all. We have a command in nushell called ansi link and I can't activate or see any link in terminal.app.

OK, so I managed to spend some time on a call with a friend to try variations on open and he said it doesn't actually execute anything inside the new terminal even if you supply a command to run after --args. That would explain why nothing works in Terminal.app.

I think that means, for now, it's best to omit MacOS and Terminal.app from the tests/osc.rs code. Since users can manually run the examples from within an already running Terminal via cargo run --example foo and Terminal is the only one the osc.rs code tries on Mac OS it's kind of pointless to stress about getting it running on Mac OS.

I considered running it via Applescript but my friend had to end our call. So I can only speculate on what the script might look like based on this StackExchange. The script file (e.g. myscript) would have something like:

tell application "Terminal"
    do script "/bin/zsh -c cargo run --example hyperlink"
end tell

Which could be run (from a command line or via the osc.rs code) with something like:

osascript -e myscript

In the next few days I'll polish the PR up some more and push hopefully the last changes before it's ready for you to run the tests again and, if that passes your standards, a decision on merging.

Thanks for your time!

[fdncred]

Testing on Windows this morning, trying to get things to work. Here's my current changes that aren't working exactly.

    term!(
        TerminalExe,
        target_family = "windows",
        "wt.exe"
    );

and

            #[cfg($plat)]
            fn exists() -> Option<bool> {
                //Some(is_executable($cmd))
                Some(true)
            }

On Windows, for wt.exe, we really just need a check to see if it's in the path versus at a particular location. I believe it changes location based on how it's installed and what version is installed. For example, this is the current location of mine C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\wt.exe.

Also, I haven't figured out how to pass commands to it programmatically. I get windows like this with cargo test --all-features -- --ignored --show-output.

This is the help for wt.exe

---------------------------
Help
---------------------------
wt - the Windows Terminal
Usage: [OPTIONS] [SUBCOMMAND]

Options:
  -h,--help                   Print this help message and exit
  -v,--version                Display the application version
  -M,--maximized Excludes: --fullscreen
                              Launch the window maximized
  -F,--fullscreen Excludes: --focus --maximized
                              Launch the window in fullscreen mode
  -f,--focus Excludes: --fullscreen
                              Launch the window in focus mode
  --pos TEXT                  Specify the position for the terminal, in "x,y" format.
  --size TEXT                 Specify the number of columns and rows for the terminal, in "c,r" format.
  -w,--window TEXT            Specify a terminal window to run the given commandline in. "0" always refers to the current window. 
  -s,--saved INT              This parameter is an internal implementation detail and should not be used.

Subcommands:
  new-tab                     Create a new tab
  nt                          An alias for the "new-tab" subcommand.
  split-pane                  Create a new split pane
  sp                          An alias for the "split-pane" subcommand.
  focus-tab                   Move focus to another tab
  ft                          An alias for the "focus-tab" subcommand.
  move-focus                  Move focus to the adjacent pane in the specified direction
  mf                          An alias for the "move-focus" subcommand.
  move-pane                   Move focused pane to another tab
  mp                          An alias for the "move-pane" subcommand.
  swap-pane                   Swap the focused pane with the adjacent pane in the specified direction
  focus-pane                  Move focus to another pane
  fp                          An alias for the "focus-pane" subcommand.


---------------------------
OK   
---------------------------

If I run it manually like this

I get these windows and they disappear after 10 seconds

[fdncred]

I'm fine with running examples manually, but we need to be able to see them work. I can't see cwd or icon doing anything. If we can't get them to produce some result, I think we should probably remove them.

Running on WSL2 I have
gnome-terminal - title and hyperlink work, can't tell on cwd and icon
rxvt - same
eterm - couldn't get to work

i haven't tried changing the code for these other terminal emulators but it's some i've heard of
st
foot
kitty
wezterm
alacritty
tabby

[mhelsley]

I'm fine with running examples manually, but we need to be able to see them work. I can't see cwd or icon doing anything. If we can't get them to produce some result, I think we should probably remove them.

That makes sense.

TL;DR / Summary:

• Remove ::cwd() (I'll make this it's own commit)
• Rename ::icon() to something more accurate (e.g. ::icon_caption() or ::icon_title()) or just Remove it too?

I'm a little hesitant to remove ::icon() because I could see it being useful somewhere. However, if you say to remove it I'll also happily do that since it means less to fix/maintain. If you want to know more detail why I hesitate there's an optional boring bit at the bottom of this comment.

Running on WSL2 I have gnome-terminal - title and hyperlink work, can't tell on cwd and icon rxvt - same eterm - couldn't get to work

Yeah, I'm having trouble with eterm as well. If I can't get it working locally and soon I'll just remove it. I think we've got enough confidence from the existing coverage and adding more terminals (on Linux) begins to have diminishing returns.

i haven't tried changing the code for these other terminal emulators but it's some i've heard of st foot kitty wezterm alacritty tabby

I've tried alacritty in the past. The issue with adding alacritty and most of the less common terminal emulators to the testing is how reliably Rust's std::process::Command would find/detect them on all the platforms. That said, I will modify the OSC test code to make it less brittle in that respect and other terminals can be added (or removed) more easily in future PRs.

---

Possible Origins of ::icon() Confusion (skip unless supremely bored)

My guess is tech cultural terseness and history resulted in my confusion at least. I now think the "icon" feature has very little to do with icons. I seem to recall in old school X Windows,when you "minimized" a window, it became an "icon" on your "root window" (modern: "the desktop"). It helped users choose among windows represented by the same icons they wanted to unminimize. But for its origins with X Windows and xterm, it might better have been described as a "brief caption" or "name" for whatever is currently running in that window rather than having anything to do with an "icon".

In the intervening years, since that UX has largely disappeared, it's become synonymous in many terminal emulators with setting the window title. It's hopelessly confused and now OSC 0, I, and 2 all seem to do exactly the same thing at least in practice. Chances are only the oldest terminal emulators (perhaps xterm) make any subtle distinction between the two.

[fdncred]

when you "minimized" a window, it became an "icon" on your "root window" (modern: "the desktop")

ah, yes. I remember this. I run SunOS 4.1.3/4 for many years and remember this.

I'll also happily do that since ...

ya, let's remove cwd and icon please.

Let me know when you're ready for more testing.

[mhelsley]

    term!(
...
        "wt.exe"
    );
...
            #[cfg($plat)]
            fn exists() -> Option<bool> {

OK, I've merged those changes in and simplified things a lot. I renamed the function ::exists() -> Option<bool> to ::try() -> bool and it only passes along the platform cfg. Then std::process::Command does the searching and checking to see if the terminal can be executed. Only if it finds and executes the terminal can the test case possibly fail. I think that will deal with the problem you described:

On Windows, for wt.exe, we really just need a check to see if it's in the path versus at a particular location. I believe it changes location based on how it's installed and what version is installed. For example, this is the current location of mine C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\wt.exe.

As for:

Also, I haven't figured out how to pass commands to it programmatically. I get windows like this with cargo test --all-features -- --ignored --show-output.

The inner double-quotes showing up inside the backticks suggests the double-quotes might be interfering with parsing the command line properly -- I'm guessing that wt.exe is adding the outer backticks around the input it received. Is there some way to submit the cargo command portion using a different combination of or perhaps even no quoting?

Since I lack access to Windows, by any chance could I submit this PR and you could fix up the Windows bits? I'm happy to respond with guesses and possible solutions for problems you encounter. I just think we've got these longer cycle times and it might become error-prone to have me modifying the PR based on your descriptions each time. That might work better unless I'm mistaken and you're unable to modify the PR too.

This is the help for wt.exe

wt - the Windows Terminal
Usage: [OPTIONS] [SUBCOMMAND]

Options:

... (I didn't see any additional promising options to use)

Subcommands:
new-tab Create a new tab
nt An alias for the "new-tab" subcommand.

The nt subcommand looks like a potential way to isolate the test from potentially messing with whatever the user is already doing in another terminal window / tab.

If I run it manually like this ... I get these windows and they disappear after 10 seconds !

OK, that looks good and I think that's sort of the ideal result (though maybe 10 seconds is too long / too short for some folks -- you folks can modify the timeout as you see fit before merging).

[mhelsley]

when you "minimized" a window, it became an "icon" on your "root window" (modern: "the desktop")

ah, yes. I remember this. I run SunOS 4.1.3/4 for many years and remember this.

I'll also happily do that since ...

ya, let's remove cwd and icon please.

Let me know when you're ready for more testing.

OK, I removed ::icon() and ::cwd(). I think it's ready for testing. I've left TODO notes in tests/osc.rs around the Windows and Mac testing portions.

I believe I've done everything I planned on doing for this PR. Let me know if you see more that needs to be fixed or I need to do something for the Mac and Windows paths in tests/osc.rs.

[fdncred]

@mhelsley I'm reconsidering the value of the osc.rs test. I mean, it's cool but if we can't get it to work cross platform, i'm not sure we should leave it in. I think I'd probably land this now if you can remove it. What are your thoughts on it?

[mhelsley]

@mhelsley I'm reconsidering the value of the osc.rs test. I mean, it's cool but if we can't get it to work cross platform, i'm not sure we should leave it in. I think I'd probably land this now if you can remove it. What are your thoughts on it?

It makes sense that the testing should be cross platform. I've moved the code into it's own local branch for now. I also merged your "remove comments" change into the commit with the examples.

[fdncred]

Thanks. Let's move forward with this!