Micro cannot open files with colon in their name

[aeadio]

Micro cannot open files with colon in their name

[JoeKar]

For me it's working:

Usually the : character needs to be escaped at the console via \: or the whole filename encapsulated with "":
micro something-2024-01-15T19\:03\:33Z.log
micro "something-2024-01-15T19:03:33Z.log"

To be honest...from my point of view this isn't a problem of micro.

[aeadio]

This is not a problem of shell escaping the colon: https://asciinema.org/a/MojjVMqT9g4yxmO87ekrbiLq2

Showing further, this is internal to Micro's open logic. Also happens with the 'open' command within Micro's console: https://asciinema.org/a/Z4S1gvhQ2kYI6lNPMXYDSwFVE

[JoeKar]

Does cat or less behave the same in your zsh?
For me the same (using '', "" & \:) works with open from within micro.

[aeadio]

Does cat or less behave the same in your zsh?

It does not. This is not a shell issue. I can use Bash or sh and get the same behavior. I can write a Python subprocess.run wrapper to call Micro with the arguments passed directly. All of these have the same behavior.

[JoeKar]

Ok, then let me guess:
You've the parsecursor option enabled in your options.

parsecursor: if enabled, this will cause micro to parse filenames such as file.txt:10:5 as requesting to open file.txt with the cursor at line 10 and column 5. The column number can also be dropped to open the file at a given line and column 0. Note that with this option enabled it is not possible to open a file such as file.txt:10:5, where :10:5 is part of the filename. It is also possible to open a file with a certain cursor location by using the +LINE:COL flag syntax. See micro -help for the command line options.

default value: false

This option now is in conflict with your or your service chosen filenames.
A potential fix is then to apply more or less the same regex pattern as it would have been opened with +LINE:COL here:
https://github.com/zyedidia/micro/blob/master/internal/util/util.go#L318

[aeadio]

Thank you. It's not obvious that this option is available, (default?) and interferes with the normal course of opening files. That should probably be mentioned somewhere conspicuous.

It also seems like the parsing could be smarter. My files did not end with a colon and a line number. They happened to contain a colon followed by many other characters that couldn't possibly be construed as a line/column indicator. Why doesn't the parser bail out in this case?

Usability wise it seems the +LINE:COL should be the only mechanism available. But if Micro is set on using filename:LINE:COL form (maybe it's for the case of opening more than 1 file?), then the parsing should probably look for an exact pattern, and treat it as a filename otherwise.

I'm satisfied for now. I've just disabled the option.

[JoeKar]

The most user wouldn't have a problem with that scenario due to the fact that it isn't the default option, but yes this option isn't intended to fail in this scenario...especially since the documentation every time refers to [FILENAME]:LINE:COL usage.

It also seems like the parsing could be smarter. My files did not end with a colon and a line number.

And it's now exactly fixed to search for that option at the end or more detailed after the filename.

[JoeKar]

You can enable parsecursor again after the PR has been merged or you fix it locally with a patch. 😉
Unfortunately the merge window isn't under my control.