Registered command lines are just command lines, not a programming language

Raymond Chen

A customer wanted to register a file extension with a complex command line that goes beyond simple string insertion.

When the user double-clicks a *.xyz file, we want it to run the Contoso program not only with the file name as a command line, but also with an additional command line argument that is a transformation of the file name.

For example, if the user double-clicks C:\Users\Chris\Awesome.xyz, we want to run the command line

"C:\Program Files\Contoso\contoso.exe" -exceptions C:\Users\Chris\Awesome.exceptions C:\Users\Chris\Awesome.xyz

if a file Awesome.exceptions exists in the same directory as Awesome.xyz. Otherwise, just launch it without the bonus -exceptions option.

We tried using %~dpn1.exceptions, but that just produces the percent sign and stuff. And it still doesn’t deal with testing whether the exceptions file exists.

The command line is just a command line with insertions. It is not a programming language. If you want a programming language, you’ll have to write a program.

For example, you could write a batch file that looks for a .exceptions file in the same directory as the file whose name was passed on the command line, and then run the contoso.exe program appropriately based on what you discover.

@echo off
if exist "%~dpn1.exceptions" (
    echo "C:\Program Files\Contoso\contoso.exe" -exceptions "%~dpn1.exceptions" "%1"
) else (
    echo "C:\Program Files\Contoso\contoso.exe" "%1"
)

You can then use this batch file as the command line.

"C:\Program Files\Contoso\Contoso-launcher.cmd" "%1"

Of course, this will display a command prompt briefly. You can write a program in a non-console language if that bothers you. At this point, the problem has been reduced to computer programming.

3 comments

Discussion is closed. Login to edit/delete existing comments.

  • GL 3

    Shameless self-plug. I encountered something similar for my own needs — when I open a PDF, if there is a corresponding TeX file in the same directory, then I want to launch the PDF viewer from the TeX suite, otherwise I want the usual reader. So I wrote https://github.com/GeeLaw/PowerShellThingies/blob/master/scripts/SurrogateUser/launchpdf.cc with the help of your blog 🙂

    References:
    1. IDropTarget local server https://devblogs.microsoft.com/oldnewthing/20100503-00/?p=14183
    2. ShellExecuteEx with lpClass set https://devblogs.microsoft.com/oldnewthing/20100701-00/?p=13543

  • Joachim Otahal 0

    Nice to see such basic stuff here too! More than one in four postings are completely beyond my level. For the second one in four I can just make enough sense of the code to know what it is about. The rest is fine with me.

  • alan robinson 0

    There’s lots of command line tools that could benefit from a simple app that would know what kinds of arguments the tool takes and even help fill them in for you with a simple dialog that knows for instance, which arguments only take numbers, which are specifying files, etc. Kind of like the robocopy gui tools that folks keep on writing, but meant to be scriptable beyond a single .EXE

    In the ideal world it could even parse the result of running “tool -h” or “tool /?” and then present all the options as a simple GUI, but of course that kind of freeform natural language parsing is a pipedream (at least before LLMs). As helpful an aid as this could be, I would never expect the OS to provide it.

Feedback usabilla icon