No parameters possible for commands runnig from command bar?

[Tom]

Create a batch called Test_command_bar_parameters.cmd with the following lines:
@echo off
echo file name = %0
echo Parameter 1 = %1
echo Parameter 2 = %2
echo Parameter 3 = %3
echo Parameter 4 = %4
echo Parameter 5 = %5
pause

Open a command prompt (cmd.exe) and run the command:
Test_command_bar_parameters.cmd This is a simple Test

You will get the following output:
file name = Test_command_bar_parameters.cmd
Parameter 1 = This
Parameter 2 = is
Parameter 3 = a
Parameter 4 = simple
Parameter 5 = Test
Press any key to continue . . .

Now run the same command from MCs command bar and you will get the output:
file name = "D:\Test_command_bar_parameters.cmd"
Parameter 1 =
Parameter 2 =
Parameter 3 =
Parameter 4 =
Parameter 5 =
Press any key to continue . . .

So only the first "word" is parsed from MC to the command prompt.

I have this behaviour with MC v6.4.8 (build 2265) 64 bit Edition on W7 and W10. Is this a bug or depends this from my settings?

[Mathias (Author)]

If you place command on the quicklaunch bar is just that. It quick launch the command. (Like the quick lunch thing in Windows XP, and  Win7 (if you unhide it))
But if you drop files on it. they can be expanded as parameters to the program you drop them on
You can also place user defined command on the quick launch bar, and they might query and get information from panels and do things based on that

[Tom]

I have a bunch of batches like InstallSoftwareXY.cmd which install the software XY on a remote PC. This batches expect the hostname as first parameter. Actually I cannot run this batches from MCs command bar like on my previous used commander programs. Let me try to explain what I usually want to do.

Normally I have the focus in one panel on the file InstallSoftwareXY.cmd. I use Ctrl+Enter to parse the file name  with following space character to the command bar. (Unfortunately the focus is not moved to the command bar). I type the target hostname manually as parameter after the parsed file name. (In MC I have to click twice in command bar, 1st will mark whole command bar, 2nd to set the focus after the file name and the following space character while in other commanders I can type directly the hostname as they set automatically the focus after the parsed file name ).

Then I press Enter to send this command (file name with following space character and target hostname) to the command line.

I don't see how MCs quicklaunch bar could really help with this.

Would it be possible to parse the whole commands given in MCs command bar to the OS command line in a future MC version? I fear that this is a KO criterium for my (and my colleagues) MC usage since every other commander I know would parse the parameters from the command bar. No possibility to type parameters on a command bar would be a very bad restriction which would not be accepted.

[Mathias (Author)]

I thought you meant that you used the quick launch bar.

Everything you send on the commandline is send as paramters..
Windows is handling that.. the entire string after a first file is sent as parameter to that command
(And you do not need to click,  by default all typed character will be sent to commandline field. so you can start to type and it ends up there or press key before '1' key to change focus to commandlien field)

if you type "notepad.exe myfile"  myfile is sent as a parameter to notepad.exe

If you use your script and and type "x.bat 1 2 3 4 5" in the command line field
I get
file name = "C:\x.bat"
Parameter 1 = 1
Parameter 2 = 2
Parameter 3 = 3
Parameter 4 = 4
Parameter 5 = 5

[Tom]

Ok, I did some further tests. If the extension is .bat then the parameters are send but if the extension is .cmd then the parameters are not send. So if you rename x.bat to x.cmd and type "x.cmd 1 2 3 4 5" you'll get empty output for the parameters.

Unfortunately all of our batches have the extension .cmd. As far as I remember in early times there existed command.com (16bit) an cmd.exe (32bit) and we used .bat for command.com batches and .cmd for 32bit batches.

Anyway, if I open a command line (cmd.exe) and run "x.bat 1 2 3 4 5" and "x.cmd 1 2 3 4 5" then I get the same output and this should also be the behaviour within MC. It's strange that MC handle this extensions differently and I have no idea why.

Of course I could type in MCs command line:
cmd /c "x.cmd 1 2 3 4 5"
and this would give the correct and expected output. But that would be only a workaround, no solution.

Can this different behaviour for .bat and .cmd be influenced in any settings? Or must this be changed internally in a future MC version?

Regarding the focus: In Explorer Panel settings, keyboard handling I tagged Quick search, untagged Search field, untagged Search for text parts anywhere in the file/folder name and defined Search keys to "Letter only / will disable "Forward keys to command bar".

If the focus is in one of the panels, then typing should position the focus to the next filename with the typed characters. That's ok and well known from other commanders. If the focus is in the command bar then the typing should go to the command bar. This is also well known from other commanders and MC works the same way.

But when I use a hotkey to send the filename (or panel directory) to the command line then MC should set the focus to the command bar since it is highly expected that I want to use the command bar for the next action. With the other "Search keys" settings you can distinguish between normal letters (for command bar) and ALT+Letters and CTRL+ALT+Letters (for active panel). In my Search keys setting "Letters only" the Quick search keys and the command bar keys would be both normal not altered keys. So it would be a great help to switch the focus to command bar if any internal command is choosen, which sends something to the command bar.

[Mathias (Author)]

there is no 16bit any more.. there is only cmd.exe and it runs both of the.. the only different is some default behavior of ERRORLEVEL variable in bat script works.
Dont know why .cmd does not work. everything should be forwarded. and windows should just run the command.

A workaround to create a bat that calls the .cmd with same paramters

[Tom]

If you only have x.cmd (no x.bat) and run "x 1 2 3 4 5" instead of "x.cmd 1 2 3 4 5" then the output is correct. So I think .cmd is misinterpreted by MC, most likely interpreted as alias command or something else.

Can you debug the MC source while running the above two commands? The first runs correct, the second in another wrong way. Debugger should be able to tell where it's going wrong.

[Tom]

If you look at the Log after you run x.cmd 1 2 3 4 5 you see:
2016-12-17 23:28:45.067 Unknown Command : "x.cmd 1 2 3 4 5"
2016-12-17 23:28:45.067 Execute using MultiCommander FileType Setup : "x.cmd"

If you look at the Log after you run x 1 2 3 4 5 you see:
2016-12-17 23:29:12.835 Unknown Command : "x 1 2 3 4 5"
2016-12-17 23:29:12.835 Execute using MultiCommander FileType Setup : "x"
2016-12-17 23:29:12.835 ShellExecute(NULL, _T("open"), "x", "1 2 3 4 5" , "E:\", SW_SHOW);
2016-12-17 23:29:12.842 ShellExecute returned without any error

So with the extension .cmd the ShellExecute isn't logged and not executed the way it should. So clearly a different handling from MC side.

[Mathias (Author)]

Actually, Both of them end up in ShellExecute..  but the first is going via FileType Setup configuration. (Menu > Config > FileType setup)

[Tom]

Thanks for the hint. Under Configuration, File Type Setup..., Launchers (Run/Open) I added:
Name = Cmd
Program Path = C:\Windows\System32\cmd.exe /c
Program Parameters = "${filepath}"
Icon = not selected
File Extensions = *.cmd
Path Matching =

With this setting the batch x.cmd 1 2 3 4 5 runs as expected and the log shows:
2016-12-18 19:45:20.661 Unknown Command : "x.cmd 1 2 3 4 5"
2016-12-18 19:45:20.661 Execute using MultiCommander FileType Setup : "x.cmd"
2016-12-18 19:45:20.705 ShellExecute(NULL, _T("open"), "x.cmd", "1 2 3 4 5" , "E:\", SW_SHOW);
2016-12-18 19:45:20.734 ShellExecute returned without any error

So finally a functional workaround. Thanks a lot.