search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.4k stars 8.3k forks source link

Can't bypass DOSkey macro with leading space #4189

Closed cniggeler closed 2 years ago

cniggeler commented 4 years ago

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):
Microsoft Windows [Version 10.0.18362.535]
Any other software? A DosKEY macro

Steps to reproduce

Create a DOSkey macro, e.g., doskey dir=dir /b Run the command, dir then run the command (note space in front) dir

Expected behavior

In the 2nd run, you should get the default "dir" listing. This is the case in classic console.

Actual behavior

You get the results of "dir /b" again!

Luuk34 commented 4 years ago

The ' dir' does not work in my default console (CMD), it will still use the alias?

cniggeler commented 4 years ago

The ' dir' does not work in my default console (CMD), it will still use the alias?

Sorry, but are you a bot? If not, are you on the Experimental Console programming team trying to replicate my reported bug? The dir command is probably the most-used command in console operation, so how could you be without one?

eryksun commented 4 years ago

It's not counter-intuitive that matching a console alias would trim leading spaces. However, the doskey docs do state plainly that the user should "type the macro name starting at the first position on the command line". Moreover, they include the following instructions for creating a macro with same name as a command:

If you always use a particular command with specific command-line options, you can create a macro that has the same name as the command. To specify whether you want to run the macro or the command, follow these guidelines:

  • To run the macro, begin typing the macro name immediately after the command prompt, with no space between the prompt and the command name.

    • To run the command, insert one or more white spaces between the command prompt and the command name.
Luuk34 commented 4 years ago

What I mean to say is that this bug report is claiming that running ' dir', after defining an alias for dir, should output the normal behavior of what is expected in CMD.

But when I tested this outside WT, I did not see this behavior. The macro is always being run, and I do not have a way to run DIR with other options than the one given in the alias.

I am running the same version of Windows, Microsoft Windows [Version 10.0.18363.535].

cniggeler commented 4 years ago

@luuk34: ah, thanks for the clarification. But eryksun has found the chapter/verse of how it should work according to the docs - thanks! - and what it's doing is definitely NOT according to the docs.

Can't speak to your situation/configuration. I've replicated it on two different machines. You do need to completely exit, then restart, your console session after unchecking/checking "use legacy console" to make the changes stick.

Also:

The macro is always being run, and I do not have a way to run DIR with other options than the one given in the alias.

Note that my original post says the way around it is to put a space before the "dir" command. That's the canonical method of bypassing a DOSkey macro with the same name as a nother command.

j4james commented 4 years ago

It looks like this should be easy to fix. I can get it working in a local build just by deleting this line:

https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/alias.cpp#L1154-L1155

But I'm curious why that trimming routine was added in the first place if it's not compatible with the legacy console. Someone from the core team will probably need to confirm whether that was a mistake and it's safe to remove.

DHowett-MSFT commented 4 years ago

Author: Michael Niksa Date: Fri Apr 27 20:38:26 2018 +0000

Merged PR 1747128: Make interactive mode command line trim leading spaces from aliases to improve usability

Per MSFT:16672211 trim spaces from alias lookups since they never resolved to anything anyway. Makes aliases a touch more useful at the cooked command line.

Paul noticed this while I was doing the alias improvement code and suggested the enhancement.

Related work items: MSFT:16672211

Looks like our usability improvement was a usability detriment. :smile:

cniggeler commented 2 years ago

Hi, it's been 2+ years and now I note this issue is still present in Windows 11! Looking at the status, I see it continues to be pushed out, and the last milestone Feb. 2 is past. Can we ensure this gets put in this time? The fix can't be that hard - don't left trim the command :-)

zadjii-msft commented 2 years ago

@cniggeler this is currently slated for the current milestone, but is fairly low priority relative to some of the other bugs in the milestone. I do believe this is a fairly easy-starter issue if you'd like to try submitting a fix yourself 😉

cniggeler commented 2 years ago

Uh, OK I'll think about it. Windows being a for-profit product I'm surprised at the suggestion of a user-contributed, free solution ;-)

cniggeler commented 2 years ago

@zadjii-msft I just found that you are in charge of this project - congrats! That being the case, what is your strategy for handling bugs? This IS a functional bug - I'm not asking about font rendering or cursor blink rate. When does the fact that this is a bug, that it's been aging two years, and that it's probably a one-line change (since you or your team would know where the line is and I don't) factor into your decision to just fix this and close it?

zadjii-msft commented 2 years ago

Lol I wish I was in charge, I just happen to be the person who drives triage.

We handle bugs more or less based off of severity, but the process is pretty arbitrary. There's plenty of bugs on the repo and our little team just doesn't have time to get to them all. This is probably an easy fix, sure, but the impact is pretty low so it's just never really bubbled up in priority. I'd guess that there's not a super large population of users that are actually using the built-in aliases functionality. If there were more folks hitting this, then it'd be more important to fix. I'd bet that the line of code identified in https://github.com/microsoft/terminal/issues/4189#issuecomment-573447367 is the one that's probably responsible. We just haven't had the time to do the diligence to confirm.

cniggeler commented 2 years ago

@zadjii-msft, Hee! Got that view from article titled, "Guy in charge of it, Mike Griese, Software Engineer at Microsoft, writing on Hacker News"

Anyway, I could at least take out the trim and try to run it, then provide you feedback. It is true that just removing the trim may not fix the issue. Would appreciate your reply on the following:

  1. Is there a makefile so I can just compile from Windows command line? I don't want to waste half a day loading it into Visual Studio and learning all the ins and outs of the code. I just wanna compile/run. (I guess you can see why a working console is important to me :-) )
  2. Where does a new terminal go once built, and how is it invoked? I have a shortcut to cmd.exe and it gives you a choice to use the legacy console or not.
zadjii-msft commented 2 years ago

Well, I'm flattered, but in 2017 I was decidedly less senior than I am even now. Fun to think people on HN thought I was "in charge of {the terminal}" for the last 5 years 😝

building.md is the definitive guide, but if you're using CMD then the easiest way to build conhost would be:

git clone https://github.com/microsoft/terminal.git
cd terminal
git submodule update --init --recursive
.\tools\razzle.cmd
nuget restore OpenConsole.sln

@rem at this step you may need to open VS to get it to pull down dependencies, the SDK, etc.
@rem start OpenConsole.sln

@rem To build just conhost, switch to this directory and run `bx`
cd src\host\exe
bx

@rem this will launch the conhost you just built
opencon

You shouldn't need to build the whole terminal for this bug, just building conhost (openconsole.exe) should be enough to test this fix. The Terminal takes quite a bit longer to build.

cniggeler commented 2 years ago

The single line change to alias.cpp as specified in the above comment seems to have done the trick! I will do some further testing, but both my issues - a leading space to prevent invoking DOSkey macro, and case sensitivity from history (separately fixed) - appear to be working fine!

OK, didn't I say I didn't want to waste 1/2 a day in Visual Studio? Well, I did :-) Things are very brittle if you have >1 Visual Studio installed, and it took me a while to get the environment set correctly (hint: rerun razzle.cmd once you get 2019 vs. 2017 set as the default build environment, which I do in a batch file on startup).

Anyway, thanks for the pointers, hope this confirmation helps!

cniggeler commented 2 years ago

@zadjii-msft How do I get the built app to run on a different machine? I studied opencon.cmd and tried the following, but I do not get anything: no messages, no new window, and nothing in tasklist:

  1. two of the files, VtPipeTerm.exe and Nihilist.exe do not exist (apparently were not built) but that does not affect running the app on the build machine
  2. copied over openconsole.exe
  3. copied it again and renamed as conhost.exe
  4. copied over conhost.dll
  5. added vcruntime140_1d.dll which doesn't exist on the other machine and got an error dialog trying to start openconsole without it.
cniggeler commented 2 years ago

Update: I've also done the following:

Can anyone help a guy out here? Thanks!

zadjii-msft commented 2 years ago

Sorry, wasn't checking mail last week. Copying openconsole to another machine should work all by itself. It should be able to be doubleclicked. Did you build it as Release or Debug? (if you just ran bx, you probably got Debug. bx rel will build the Release version).

  1. two of the files, VtPipeTerm.exe and Nihilist.exe do not exist (apparently were not built) but that does not affect running the app on the build machine

That's fine, those are just test binaries

I'm pretty sure the only thing that's needed is openconsole.exe, and the right version of the c runtime. console.dll is only needed for changes to the property sheet.

The C Runtime is required though. Pretty sure VS installs that for you with the rest of the tools, but you should be able to get it from here manually.

cniggeler commented 2 years ago

QUICK COMMENT: Sorry about formatting, tried to copy/paste info into code tags.

Still no dice :-( bx rel built fine with one warning (spacing is straight copy from console): ` "c:\devel\terminal\OpenConsole.sln" (Conhost\Host_EXE target) (1) -> "c:\devel\terminal\src\host\exe\Host.EXE.vcxproj.metaproj" (default targ et) (2) -> "c:\devel\terminal\src\host\proxy\Host.Proxy.vcxproj" (default target) ( 3) -> (Link target) -> LINK : warning LNK4266: missing load config symbol for image built wit h /GUARD [c:\devel\terminal\src\host\proxy\Host.Proxy.vcxproj]

1 Warning(s)
0 Error(s)`

The C runtimes are a common requirement, the version on my laptop was older, but installing the latest did not help. In comparing what was installed in Programs and Features, I found some discrepancies - perhaps .NET framework or its SDK is required? Or what about the version of the Windows SDK? Here are the diffs '<' is build system, '>' is test system: `< Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.29.30139

older version: 14.26.28720 updated to latest: 14.31.31103

< Microsoft .NET Framework 4.8 SDK < Targeting Pack < Targeting Pack (ENU)

None! < Microsoft .NET SDK 5.0.406 (x64) from Visual Studio None!

< Windows Software Development Kit - Windows 10.0.14393.33 to 10.0.22000.194

                                       10.0.17134.12 to 10.0.17763.132

< CLR types for SQL server 2019 CTP2.2

CLR types for SQL server vNext CTP 1.6
< Sync Framework 2.0 Core and Provider Same`

zadjii-msft commented 2 years ago

Oh that might do it. Hard to exactly parse that, but 10.0.17134.12 is quite a bit out of date at this point. I would not be surprised at all if the current conhost builds don't run on that version of windows 10 anymore.

DHowett commented 2 years ago

Huh, this is pretty curious.

Would you be able to run it under the debugger after enabling loader snaps?

When you run OpenConsole under the debugger, it should emit a terrible volume of text about library loading, symbol binding, etc. that might help figure out why it won't load on this machine. :smile:

DHowett commented 2 years ago

Oh that might do it. Hard to exactly parse that, but 10.0.17134.12 is quite a bit out of date at this point. I would not be surprised at all if the current conhost builds don't run on that version of windows 10 anymore.

Hmm. Quite possible... but to my knowledge we haven't made any changes that would exclude running on that version.

In addition, I think @cniggeler was only stating that they have that SDK installed (not that they're running on that version of Windows!)

cniggeler commented 2 years ago

I'm running Windows 10 Pro 21H1. Microsoft Windows [Version 10.0.19044.1586]. @DHowett is correct that that was the version for the SDK.

I will run openconsole through windbg with loader snaps and reply next.

cniggeler commented 2 years ago

@DHowett I loaded gflags and checked loader snaps as requested. I pressed Launch, which had no visual feedback, so I returned to Windbg. There is now 2155 lines of info, which I've attached as a text file. opencon_snap.txt

I have VS2017 loaded on the test machine. Would it be possible/ advisable to build with debug info on the VS2019 build machine and then open the debug .exe in VS2017 on the test machine?

DHowett commented 2 years ago

It looks like everything we need is loading; any libraries that can't be found (Status c0000135) later get picked up from the system directory.

Can you generate a backtrace when you get here? I wonder if we're exiting in an orderly fashion for some reason...

image

A debug build might help. You'll have to copy over the debug CRT (from the VC\ directory in your VS 2019 install!)

cniggeler commented 2 years ago

I'm assuming you meant View - Call stack: opencon_bt

Also, here's the output after selecting GO, which adds another 1050 lines of output: opencon_go.txt

DHowett commented 2 years ago

Indeed!

It looks like the console is choosing to exit at +0xdb7a4. If you copy the pdb for OpenConsole from your build machine to the run you're running on, you'll get a bit more info. It could just be returning from main after failing to do something, admittedly... but nothing in that loader snap log looks wrong.

cniggeler commented 2 years ago

I think this took. I kept getting message WARNING: Non-directory path: 'C:\temp\OpenConsole.pdb' even after using "Browse" in windbg. Anyway, slightly larger file attached: opencon_w_pdb.txt

DHowett commented 2 years ago

And what's the call stack at termination for that build? :)

cniggeler commented 2 years ago

Has a function name in it :-)

opencon_bt2

cniggeler commented 2 years ago

Update: I also tried this on a brand new Win11 machine. Installed the latest C runtime and copied the release version of OpenConsole.exe to it. It also does not run.

DHowett commented 2 years ago

You know, I'm still stumped by this. Sorry to leave you on read.

Here's what I'll say: You can send out a pull request if you'd like, without further validation. The CI will take care of producing a runnable copy of this kit and kaboodle and then actually run it on your behalf :smile:

To be fair, trying to validate something on multiple machines is farther than I suspect most of the team usually goes :grin:

cniggeler commented 2 years ago

Thanks. At this stage I was more interested in why the build wasn't able to run on different machines, because maybe that would point out some corrective action in the build scripts or execution prerequisites. But I would love to have it on my main machine where I work every day - been waiting 2.25 years for it!

The change was literally the one line change above, and a pull request seems heavyweight. Is there an alternative to just add it to the branch for the next scheduled release? My build/test has managed to show it works ;-)

ghost commented 2 years ago

:tada:This issue was addressed in #13476, which has now been successfully released as Windows Terminal Preview v1.15.200.:tada:

Handy links:

cniggeler commented 2 years ago

I'm trying v1.15.200 and am encountering problems for which I've entered a separate comment under its release. My questions here are,

Thanks!

Luuk34 commented 2 years ago

I'm trying v1.15.200 and am encountering problems for which I've entered a separate comment under its release. My questions here are,

  • Is Terminal intended to replace cmd.exe?

The Windows Terminal is a modern, fast, efficient, powerful, and productive terminal application for users of command-line tools and shells like Command Prompt, PowerShell, and WSL. Its main features include multiple tabs, panes, Unicode and UTF-8 character support, a GPU accelerated text rendering engine, and custom themes, styles, and configurations. (see: https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701?l=en

In other words Terminal is an app which combines the functionality of different shells.

  • What happens when I UNcheck "Use legacy console" in the cmd.exe Properties - is that supposed to start this Terminal - because it's not, I continue to get the old doskey behavior.

see: Legacy Console Mode

  • How do I get in/out of the legacy/ new console behavior is via this Properties checkbox in cmd.exe... or am I just supposed to create a shortcut to wt.exe instead?

?

Thanks!

cniggeler commented 2 years ago

Thanks for the reply! Some of this raises more questions than it answers.

see: Legacy Console Mode

This link references "the Console Host team". Who is that?

In Task Manager, the "Windows Command Processor" app is comprised of two components: Console Windows Host (conhost.exe) and (the recursively named) Windows Command Processor (cmd.exe). But if I try to run conhost.exe by itself, nothing happens (Run... type in conhost, no window opens).

Then, in the next paragraph, that linked page says "If you experience an issue that requires you to use the legacy console that is not documented here, please contact the team on the microsoft/terminal GitHub repository." This is how/why I opened this ticket regarding doskey.

Is the Terminal team different from the Console Host team?

This is still unclear: if I UNcheck "Use legacy console" in the conhost console that comes up when I run cmd.exe, what application is then run - is it Terminal? Because if it is, I can say for sure that the Terminal Preview v1.15.200 is NOT being accessed. Or is it instead some extended mode of conhost.exe?

All of which lead me to ask my last question, which I will try to rephrase in a couple questions:

Thanks!

Luuk34 commented 2 years ago

@sniggler: too much questions for /me to answer (and not make any mistakes, or wrong assumptions), I will leave that to the Team which is responsible for this 😉

cniggeler commented 7 months ago

Despite the merge and closed-fixed claim in #13476 afraid this is still not fixed in 1.19.10573.0! The test process is the same as it's always been.