Controlling the execution of a command line

[mayevski]

Hello,

I'd like to ask or maybe request a feature about the following: I'd like to change the way an expression in the command line gets executed. As far as I understand it, the expression goes to Windows "as is" (or by running "cmd.exe /c <command>" ? ). It would be great if there were an option where one could specify the command line to run instead of the currently used mode.

Why so: I'd like the commands to be run in the nushell interpreter run within Windows Terminal (no cmd.exe at all). Right now, cmd.exe is started regardless of the system console host settings (in which you can set Windows Terminal to be the default host for console apps).

Examples of an option value:

nu -c "%commandline%"
(this would run nushell and let it quit after the command is executed)

nu -e "%commandlineescaped%"
(this would run nushell and keep it). "Escaped" here means that backslashes should be duplicated in the command line. Maybe, other characters should be escaped too. This is a hard question because different applications may have different escaping rule, and without escaping, the whole feature may be useless.

Sincerely yours
Eugene Mayevski

[ghisler(Author)]

Enter should run the command directly, while Shift+Enter uses noclose.exe, which uses cmd.exe /K with the command.
You could replace noclose.exe with your own launcher.

[mayevski]

"directly", unfortunately, launches cmd.exe (which matters because the command line syntax is different between cmd.exe and nushell). That's what the request is about.

Regarding noclose - this is a good option, but a bit hackery, especially for people who say don't write code.

Another possible approach - instead of adding an option, add some hook/plugin type so that one can write a plugin, which will handle the command line execution. A replacement of noclose(64).exe would be such a plugin, indeed, but it handles only shift-enter and not enter.

[white]

"directly", unfortunately, launches cmd.exe (which matters because the command line syntax is different between cmd.exe and nushell). That's what the request is about.

No, "directly" means similar to Windows Run. Programs started on TC's command line (when not using Shift+Enter) are started directly without launching cmd.exe.

[mayevski]

"directly", unfortunately, launches cmd.exe (which matters because the command line syntax is different between cmd.exe and nushell). That's what the request is about.

No, "directly" means similar to Windows Run. Programs started on TC's command line (when not using Shift+Enter) are started directly without launching cmd.exe.

What the code does and what the outcome is are two different things. What it does - launches "directly" - using which WinAPI function? Is it ShellExecute or CreateProcess or something more sophisticated?

The outcome is that cmd.exe is started by the OS, and I would like it to be nushell.

[white]

What the code does and what the outcome is are two different things. What it does - launches "directly" - using which WinAPI function? Is it ShellExecute or CreateProcess or something more sophisticated?

The outcome is that cmd.exe is started by the OS, and I would like it to be nushell.

I'm afraid there's a bit of a misunderstanding. You were correct before when you said this:

As far as I understand it, the expression goes to Windows "as is" (or by running "cmd.exe /c <command>" ? ). It would be great if there were an option where one could specify the command line to run instead of the currently used mode.

So "directly" means "as is".

You are correct that some of the commands are executed using "cmd.exe /c <command>". Your suggestion is that in this case the command being used to execute the command ("cmd.exe /c <command>") is configurable, which is indeed currently not possible.

Right now, cmd.exe is started regardless of the system console host settings (in which you can set Windows Terminal to be the default host for console apps).

When cmd.exe is started, Terminal is used depending on system settings. But this is not the case when cmd.exe is run as Administrator. That has nothing to do with TC.

Perhaps command line aliases are useful to you. Or user-defined commands (em_ commands) if you want to use the commands in other places too (like the button bar).

[mayevski]

Thank you for the detailed explanation.

You are correct that some of the commands are executed using "cmd.exe /c <command>". Your suggestion is that in this case the command being used to execute the command ("cmd.exe /c <command>") is configurable, which is indeed currently not possible.

Yes, this is what this topic exists for . I considered replacing cmd.exe with some redirector, but Windows will "repair" the file, making the replacement impossible. Also, this is risky, as cmd.exe is the interpreter for .cmd and .bat files.

[ghisler(Author)]

As far as I understand it, the expression goes to Windows "as is" (or by running "cmd.exe /c <command>" ? ). It would be great if there were an option where one could specify the command line to run instead of the currently used mode.

Can't you control this via the COMSPEC environment variable?

[white]

As far as I understand it, the expression goes to Windows "as is" (or by running "cmd.exe /c <command>" ? ). It would be great if there were an option where one could specify the command line to run instead of the currently used mode.

Can't you control this via the COMSPEC environment variable?

On a Windows 10 32-bit virtual machine, I did this: In a command prompt window, I set comspec to c:\windows\system32\command.com and I launched TC. It still used cmd.exe and not command.com. It seems TC looks for cmd.exe first.

[ghisler(Author)]

What command did you try?
I tried this on a command line:
set COMSPEC=c:\windows\notepad.exe
totalcmd64.exe
Then tried to run a command like dir, ren or del on the command line at the bottom.
-> notepad was opened.

Please note that noclose.exe (for Shift+Enter) currently has cmd.exe hard coded (and will have the path to cmd.exe hard coded in the next version).

[white]

Confirmed. I found out what I did differently. As I said, I did this:

On a Windows 10 32-bit virtual machine, I did this: In a command prompt window, I set comspec to c:\windows\system32\command.com and I launched TC. It still used cmd.exe and not command.com. It seems TC looks for cmd.exe first.

But when I tried it, I run TC as Administrator. And then TC seems to ignore COMSPEC.

[ghisler(Author)]

It doesn't ignore COMSPEC as Administrator. Maybe COMSPEC has a different value with TC running as administrator?
Try running cmd.exe from TC (running as Administrator) and check the value of the COMSPEC variable.

Where did you change COMSPEC? If I just change it within cmd.exe, then elevated TC still sees the old variable.
I have to change it in Windows settings: Serach for the word env, click on "Change environment variables", and change it unter the "System variables" section.

[white]

It doesn't ignore COMSPEC as Administrator. Maybe COMSPEC has a different value with TC running as administrator?
Try running cmd.exe from TC (running as Administrator) and check the value of the COMSPEC variable.

You are right. My mistake. COMSPEC has a different value with TC running as administrator and I didn't notice it.