Feature: Support `Files .` to open current path from cli

[NightWatcher314]

What feature or improvement do you think would benefit Files?

For example, I can use "files.exe ." to open files.app in current path. Just same as "explorer.exe ." . I don't know is there any cli.

Requirements

• Post some clis

Files Version

3.1.0.0

Windows Version

10.0.22631.2861

Comments

No response

[yaira2]

Launching using Files . is not supported yet, but if you set Files as the default file manager, running explorer . will open Files with the current path.

[NightWatcher314]

I have set files as my default file manager and restart my computer. But when i use explorer . or explorer.exe . in terminal, it still open win11's file manager.

[NightWatcher314]

I have set files as my default file manager and restart my computer. But when i use explorer . or explorer.exe . in terminal, it still open win11's file manager.

OK, I have found the problem. When I use powershell, it won't work well, but cmd does. Can you add support to powershell? Thanks.

[yaira2]

👍

[saikotek]

@yaira2

I tried to invoke Files from either Powershell or cmd and I noticed that the method Files.App.OnActivatedAsync() is called with the ILaunchActivatedEventArgs type instead of the ICommandLineActivatedEventArgs type and the latter is the one that you'd expect and that contains current directory path. According to this: https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.activation.commandlineactivatedeventargs?view=winrt-22621 application should define AppExecutionAlias which is already defined in Package manifest.

I'm not sure what could be causing it.

[hishitetsu]

It is difficult to fix this because it doesn't seem to be possible to get the current directory on the command line without an update to WinUI. See #10575

[0x5bfa]

A .NET console project Files.App.CLI or Files.App.Console and register it as an alias files.exe of Files.App

<uap3:Extension
    Category="windows.appExecutionAlias"
    Executable="files-cli.exe"
    EntryPoint="Windows.FullTrustApplication">
    <uap3:AppExecutionAlias>
        <desktop:ExecutionAlias Alias="files.exe" />
    </uap3:AppExecutionAlias>
</uap3:Extension>

Sample usage

C:\> files --help

Copyright (c) 2024 Files Community
Licensed under the MIT License.

files [[<drive>:]<path>] [-s|--select] [-f|--folder] [-v|--version] [-h|--help]

  -h, --help                Display usage of this CLI.
  -s, --select              Select one or more file(s) and folder(s) on folder view.
  -f, --folder              Go to a folder specified.
  -v, --version             Display current version of this CLI.

C:\> files --version

Copyright (c) 2024 Files Community
Licensed under the MIT License.

Files version: 3.5.25

C:\> files .

Launching Files on current folder...

C:\>

Semi-related matters

With this introduction, we'll have a strong power for FileOpenDialog and FileSaveDialog implementations. Current technical issue with those overridden dialogs is where the project (Files.App.OpenDialog and .SaveDialog) cannot pass information of the dialog (dialog caller can modify footer content of the dialog, adding a button for example) to Files app via command-line (truly difficult because passing as string would require serialization and deserialization. If we introduced our own COM interfaces as IPC in Files app this issue could be fixed.

<com:Extension Category="windows.comServer">
    <com:ComServer>
        <com:ExeServer Executable="$targetnametoken$.exe" DisplayName="Files">
            <com:Class Id ="4B115281-32F0-11cf-AC85-444553540000" DisplayName="..." ProgId="Files.Commandline.1" VersionIndependentProgId="Files.Commandline">
            </com:Class>
        </com:ExeServer>
        <!– ProgId –>
        <com:ProgId Id="Files.Commandline" CurrentVersion="Files.Commandline.1" />
        <com:ProgId Id="Files.Commandline.1" Clsid="4B115281-32F0-11cf-AC85-444553540000" />
    </com:ComServer>
</com:Extension>

<com:Extension Category="windows.comInterface">
    <com:ComInterface>
    <!– Interfaces –>
    <!– IID_FilesCommandLineReciever –>
    <com:Interface Id="0BDD0E81-0DD7-11cf-BBA8-444553540000" UseUniversalMarshaler="true">
        <com:TypeLib Id="4B115284-32F0-11cf-AC85-444553540000" VersionNumber="1.0" />
    </com:Interface>
    <!– TypeLib –>
    <com:TypeLib Id="4B115284-32F0-11cf-AC85-444553540000">
        <com:Version DisplayName = "..." VersionNumber="1.0" LocaleId="0" LibraryFlag="0">
            <com:Win32Path Path="..." />
        </com:Version>
    </com:TypeLib>
</com:Extension>

[ComImport(...)]
public interface FilesFileOpenDialogReciever
{
    void Advise(IFileDialogClosedSink *pfdcs);

    void Launch(FileDialogInformation *pfdi);
}

[ComImport(...)]
public interface IFileDialogClosedSink
{
    void PostSelected(string path);
}

[0x5bfa]

@yaira2 what do you think?

[0x5bfa]

With an issue with WinUI, WinUI packaged application cannot output string to console using System.Console.Write or WriteLine. But this is actual .NET console application so you can output help message and anything that.

[yaira2]

I'd prefer for this to be resolved via the framework but it's good to have this option as a backup.

[Josh65-2201]

This will be available in the next update.