Micro cannot open files with colon in their name

[aeadio]

Description of the problem or steps to reproduce

Many log files I deal with are in the zulu time format, like something-2024-01-15T19:03:33Z.log. These are valid UNIX filenames. Micro is unable to open these files. Instead, it tries to open a non-existent file whose name ends before the first colon in the filename (in this example, something-2024-01-15T19). I don't see any mechanism to escape this behavior.

I've seen a couple of tickets referencing this, but they all seem to be closed, with even partial workaround alluded to but not spelled out in the ticket. This is still an issue as of the current version of Micro.

Specifications

Version: 2.0.13
Commit hash: Unknown
Compiled on Unknown*
OS: Void Linux (rolling)
Terminal: Alacritty 0.13.1

*-- Built from my distro. We don't seem to be doing anything special: https://github.com/void-linux/void-packages/blob/78bf2e3347a460dd3968e3655120a7aea5d51ae4/srcpkgs/micro/template

[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.