Consider a .m3u (video playlist) file. We can open this in several quite different applications, for example...

C:\Program Files\VLC\VLC.exe      -->   Read the file and play a series of video it specifies
C:\Windows\system32\notepad.exe   -->   Edit the contents of the file, specifying a new list of videos

I know (in Windows) I can open the file in either app as follows (what I will call the...)

"Command File" syntax

C:\> "C:\Program Files\VLC\VLC.exe" Playlist.m3u        -->   opens Playlist.m3u in VLC
C:\> "C:\Windows\system32\notepad.exe" Playlist.m3u     -->   opens Playlist.m3u in notepad

"File Command" syntax (?)

I wondered if it's possible to reverse this (calling the file first, then then application), e.g. ...

C:\> Playlist.m3u "C:\Windows\system32\notepad.exe"     -->   ❌ Opens Playlist.m3u in the default app (ignores everything after the filename)
C:\> Playlist.m3u | "C:\Windows\system32\notepad.exe"   -->   ❌ Opens Playlist.m3u in the default app AND open notepad.exe (but not to edit Playlist.m3u, just opens app)

Is this syntax (or something similar) possible?

Thanks in advance!

  • 2
    Short answer: No
    – DavidPostill
    May 21 at 12:41
  • probably the closest would be Invoke-Item alias ii in PowerShell, which simply executes stuff with their default app. that wouldn't be in your syntax though. ii "C:\somefile\abc.m3u","notepad.exe"
    – SimonS
    May 21 at 12:50
  • What possible reason could you have to need this? I can't think of a single case where the order can't be reworked through code. Please tell me and I might learn something. May 21 at 14:09
  • @DavidPostill - OK, thanks... will see if anyone comes up with a creative idea, but thought this might be the case. Thanks anyway.
    – Martin
    May 21 at 19:20
  • 1
    @Martin, I don;t know if you have ever attempted to write a cli executable, but on whatever platform (I've done windows and linux) a surprising amount of effort goes into the "glue-code" that projects parameters, and accepts arguments from the shell. the executable needs to be intimately familiar with the arguments its going to receive. in order to do what you describe, then all apps would have to have implemented a parameter for a content file path, in the exact same way, so that the shell could invoke the argument you pass as an executable and expect it to accept a filename universally. May 29 at 4:35

In PowerShell, you can achieve your syntax like this:

"C:\Playlist.m3u" | %{notepad.exe $_}
"C:\Playlist.m3u" | %{&"C:\Program Files\VideoLAN\VLC\VLC.exe" $_}

It pipes the path to the invocation of the executable and adds it as an argument.

  • Thanks @stackprotector! (PS: Is nice to know that my original thought to use | wasn't too far off the mark), so thank you for providing the full/specific syntax for how to do this! 👍🏼
    – Martin
    Jun 4 at 21:55
  • #Meta: Am not sure exactly what the protocol is, as had previously accepted an answer from another another contributor). The answer from Frank Thomas (and the majority of comments) generally advise against trying to use a 'File Command' syntax (which I accept is worth noting)... However, at the same time, I want to recognise your contribution - particularly as you have provided the actual technical answer to my question!
    – Martin
    Jun 4 at 21:59
  • You are free to accept any answer you want. The best practice is to mark the answer that helped you the most. And you may change it in the future if you get an even better answer. Jun 5 at 7:40
  • @Martin I agree that a "file command" syntax is not very common. And I have to point out, that my answer is not exactly what you were looking for (I guess). It is capable of way more. The % sign is an alias for the Foreach-Object cmdlet. Thus, you can also use this syntax to open multiple files: "C:\Playlist_1.m3u", "C:\Playlist_2.m3u" | %{notepad.exe $_}. So a little more logic than expected, I guess. Jun 5 at 7:49

So Windows applies a concept called "File Type Associations" or "Default Programs" or "Default Apps" depending on your version, but they all do the same thing. they associate a files extension (eg m3u) with an application and optionally a set of arguments.

The goal of a file type association, is to allow you to simply open a content file, without having to tell the shell what application you want to use to process it. Windows will simply open the associated/default application and load that file.

so if you want control over the applciation working with the file, you have to launch the application, and load the file (either by passing it as an argument via cli, or using Open With from the explorer context menu), or you can simply open the file, and let the file type association determine which application to launch.

The fundamental flaw in your approach, is that a command shell doesn't really recognize non-executable files as "commands". Executable files can be invoked, but content files cannot, without using an executable of some kind. So windows reacts to your second set of commands the only way it can; by invoking the executable associated with that filetype, and passing the content file to that executable as an argument.

All of this really comes down to the ability to execute logic. An application/command can make decisions. a content file cannot. whatever you put in as the first token you send to a command shell must be a command/executable because something has to process the rest of the statement you typed in. Windows tries to help you by opening the default application if you attempt to invoke a non-executable file, because that's all it can do.

  • Hi @Frank, thanks for your answer... I appreciate the comments (and dissuasions) from everyone (to be fair, I did realise myself that this wasn't exactly the "standard" way of structuring a shell command, but was nonetheless keen to understand if this was possible / how this could be done) -- but I think the above answer from Frank (and especially the last paragraph) really hit the nail on the head as to why this syntax doesn't (and will never) work... TLDR; "it comes down to the ability to execute logic - an application/command can make decisions. a file cannot"
    – Martin
    Jun 1 at 14:37

There are two types of programs in Windows. Console and Graphical. They are programmed quite differently, normally.

The difference from Windows starting a program perspective is that console programs automatically get a console. That's it.

It can't actually use the console without more setting up.

As graphical programs don't get a console, although they can ask for one or attach to an existing one, they don't support StdIn or StdOut which is a console thing.

  • Thanks for your answer. I appreciate what you've said, however am not sure it relates directly to my question. In the interim, other members have posted additional info and solutions for this (so think this is resolved now / won't ask you to take up any more of your time on this), however I did not want you to feel your contribution was ignored/unrecognised.
    – Martin
    Jun 4 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.