Thanks for the feedback! It now also is implemented for the remote filesystem, with windows support, and has been added to the download command.

Maybe it's a good idea to combine ParameterParsers and Completers into a ParameterType?

I'm crazy late to this conversation, but trying to clean up here. I've been away from this project for a bit.

I have a couple implementation comments. We shouldn't need to do the testing for tilde's and such manually. There are routines to do this already.

• In the case of local files,os.path.expanduser will do nothing if there isn't a tilde. We can call it regardless, which falls back to the OS routines to do parsing. This is ideal.
• Similarly, we can usesession.platform.Path(value).expanduser() so we don't reinvent that wheel. The generic implementation handles~/path/to/file and~username/path/to/file and is atpwncat/platform/__init__.py:153.

Regarding theParamType stuff, I think this is kind of re-inventing someargparse options that we could use. We can do a similar thing, but with thetype argument to the argparse object. Currently, there's a weird syntax for that, but I can update it. Doing this technically works right now:

classCommand(CommandDefinition):defexpand_remote(self,path):returnself.manager.target.platform.Path(path).expanduser()ARGS= {"test":Parameter(Complete.REMOTE_FILE,type=("method",expand_remote))  }

Basically,pwncat passing a majority of the arguments toParameter on directly to theadd_argument method from argparse. However, in the case oftype, it will wrap your method so that it receives a reference toself if you assign it in that way.

There's two things wrong with that:

1. It's cumbersome (the("method", function) syntax is awkward.
2. It's a lot of boilerplate.

Those two problems are pretty easy to solve. First, I can change thetype argument to always be a callable that acceptsself. I did that forchoices and it has worked very well, so I don't see why it wouldn't work here. Second, we can create similar helpers to what you did, but just a little simpler. E.g.

# Defined in `pwncat/commands/__init__.py` for all commands to usedefRemotePathType(parser,path):returnparser.manager.target.platform.Path(path).expanduser()defLocalPathType(parser,path):returnpathlib.Path(path).expanduser()# Example of usageclassCommand(CommandDefinition):ARGS= {"test":Parameter(Complete.REMOTE_FILE,type=RemoteFileType)  }

The upside with the above implementation is that the resultingargs.test variable would be a path-like object automatically, which is kind of nice for implementing commands that work with paths. We could even go so far as specially interpretingComplete.REMOTE_FILE andComplete.LOCAL_FILE to automatically assign thetype argument, but I'm not sure if that's a good idea. It feels kind of like "black magic" that will confuse people.

I'm going to work with this a bit on my end to see which solution I personally like the best. I'm still not sure if I want the paths to be automatically expanded. In the case of downloading/uploading files, that's true, but it may not always be true, and may cause problems if paths are mutated in the backend of the code without the user knowing what's happening.