feat: prevent paths from being treated as options in file command

[gaesa]

No description provided.

[sxyazi]

Thanks for the PR! Could you explain a bit what issue it solves? i.e. in what cases and with which filenames would they be treated as options? Also, does it work on non-Unix platforms like Windows?

[gaesa]

The change addresses an issue where file paths, especially those starting with a -, could be misinterpreted as command options by the file command. For instance, a file named -filename would be treated as an option rather than a filename, causing the command to fail in processing the file correctly. In fact, -- before file paths is a standard practice to prevent this kind of issue with command-line tools.

I have tested this in a Windows virtual machine using the file command provided by Git. In this environment, file also requires the -- argument to correctly handle paths starting with -. Without this argument, such filenames are still interpreted as options, resulting in errors. Therefore, adding -- is necessary not only for Unix-like systems but also in Git environments on Windows.

[sxyazi]

especially those starting with a -

Sorry, I still don't quite understand the issue. These file paths are always absolute paths, meaning a filename like just -filename could never exist. Instead, it would at least be something like /-filename or /root/-filename. Could you share which file paths you encountered that couldn't be processed?

[gaesa]

Thank you for your clarification.

You are correct that if the program is always using absolute paths, then the issue of filenames starting with a - misinterpreted as options wouldn't occur in practice. Adding -- in this case would not have any functional impact.

However, I would like to highlight a couple of points regarding this change:

1. Safety: Including -- is a defensive programming practice that ensures robustness, even if the current implementation only uses absolute paths. It acts as a safeguard for any potential future changes to the code that might introduce relative paths or user input scenarios where filenames starting with - could exist.

2. No Harm Done: Adding -- doesn’t negatively impact functionality. While it may slightly increase the size of the command arguments, this is generally negligible unless working in extremely constrained environments. The benefits of explicitly indicating the end of options often outweigh the minor overhead.

In conclusion, while the current implementation might not require --, including it could provide an extra layer of safety and clarity, which is always valuable in software development.

Thank you for considering this perspective.

[sxyazi]

I see your point. My thoughts and concerns are that if something isn't broken, it's better not to touch it.

Yet since file is an external dependency, its behavior might differ across versions or systems - I've noticed some of these differences over time, for example, the version installed via Scoop doesn't support Unicode filenames, and older versions of file use x- while newer ones don't.

So, I have some doubts about whether the support for -- will be consistent as well. That said, I think I'm okay with accepting this PR because we'll never know the answer without trying, I'll go ahead and merge it now.

[sxyazi]

Thanks!

[sxyazi]

I changed the title to feat: instead of fix: since it's not an existing bug fix but rather a security enhancement, hope that's fine with you :)