File names with spaces cannot be opened

[ddnexus]

same as #10 but with spaces. I suspect there might be other characters that need to be escaped.

[issue-label-bot]

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.96. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[SleepyBag]

I suspect there might be other characters that need to be escaped.

Problem with other characters are solved by one command:

printf %q "$target"

However problem with spaces is somewhat complicated. It's not about escaping but about parsing. With the presence of links, I cannot come up with a good method to parse filename from a line.

Currently I take the specified column as filename from the file list. As you can see, it cannot deal with filename with spaces.

But neither can I take from the specified column to the last because a link is shown as below:

lrwxrwxrwx    9 qmxue  6 5月   0:53 foo -> bar

I cannot split filename by -> because foo -> bar may be the name of a file itself...

I'll look into this, but it may take time.

[ddnexus]

I'll look into this, but it may take time.

No problem for the time. I open the issues that I find to be useful to your project. I can live with this particular problem.

I cannot split filename by -> because foo -> bar may be the name of a file itself...

In that case the whole line would not start with l (lrwxrwxrwx 9 qmxue 6 5月 0:53 foo -> bar) but with .rwxrwxrwx

[SleepyBag]

In that case the whole line would not start with l (lrwxrwxrwx 9 qmxue 6 5月 0:53 foo -> bar) but with .rwxrwxrwx

Yeah I know this. But if there is a link file named "foo -> bar"... This may be a minor problem, but I think there should be some clean way to solve this kind of problem.

[SleepyBag]

ls comes with an option -L which make it not show the destination of links. But exa doesn't have this option. Maybe we can just contribute to exa and make it possible. I don't think it important to see where a link referring.

[ddnexus]

Right, but that's beyond my skills.

[ddnexus]

Actually I used the ls -l to check link and target a lot, so that would be quite useful to me.
What is missing is a way to split link and target. I will try to think some solution...

[ddnexus]

I thought about the problem, and splitting on the (last) -> would only fail IF the user is using exa AND the target name would contain a -> (i.e. space->space) AND the target is in the same dir.

Indeed ls wraps with quotes all the names with spaces, so it is easy to parse. That is actually the enhancement that should be proposed to exa and would solve the problem. You may want contribute to comment on a 3 years old issue in exa.

Meanwhile IF the user prefers exa then there is a very unlikely possibility that the selection would fail, and you could state it in the README as a known issue related to exa.

So here is the reasonment for non-quoted handling:

If the -> is part of the link name (and not the target), splitting on the last -> would still get the right file.

If the target is outside the current dir, then it would be either an absolute path starting with / or a relative path starting with ../ so easily detectable.

So the only case that would fail with exa is when the target name contain a -> (i.e. space->space) AND the target is in the same dir.

In conclusion the issue would be extremely unlikely to happen, so I think it's fair ignoring it from development efforts (at east for now), and reporting it as a known issue very unlikely to happen.

Accepting it as an known issue, and implementing a different strategy to handle the non-quoted exa strings would at least solve the not-so-unlikely issue with all the files that contain a space.

What do you think?

[SleepyBag]

Yeah, parsing in a hard way may work, as you say. But I'm thinking if there a better way to map selected line to file name.
What I've came up with is that we can get the file list first by ls. And then we get the information of each file by exa -ld $filename. This way I could get the map from line to file name at the start, instead of parse filename from a somewhat mal-formatted line. This method works nearly perfectly now, but with one problem:
exa -ld $filename for each file may return lines of different length. For example, if two files are of different size, the printed lines would be mal-aligned. Like this:

.rw-r--r--  8.4k qmxue 21 7月  22:49 yankring_history_v2.txt
drwxr-xr-x  - qmxue 31 7月  22:03 zhihu

[ddnexus]

get the information of each file by exa -ld $filename

that looks like very inefficient and kind of hacky, besides being misaligned

I can live without the space parsing if that is too difficult, especially because it's a choice: if I want exa I know that's the limit. It's fine. I don't think that small problem is worth all that work and hacking, but it's up to you of course.

[ddnexus]

Another hacky option would be parsig the code colors, since exa colors link and target different. Of course it would not work in absence of color.
Again, I don't think it's worth that effort though.

[SleepyBag]

Yeah, you're right. Finally I remain the corner case there. Fixed with parsing " -> " for links.

[ddnexus]

It works well! Thank you!!!

[ddnexus]

If there is a link with " -> " in its name, it will not be opened. Though this situation is nearly impossible.

It's actually better than that. This works no problem:

$ ls -l
-rw-rw-r-- 1 dd dd 11 Oct 30 06:48  bar
lrwxrwxrwx 1 dd dd  3 Oct 29 18:15 'foo -> bar' -> bar

But this does not, even using ls:

ls -l
-rw-rw-r-- 1 dd dd 15 Oct 30 07:02 'a -> b'
lrwxrwxrwx 1 dd dd  6 Oct 30 07:01  quux -> 'a -> b'

I see that you do the same thing both for ls and for exa. I guess to keep the code simple... which considering the low possibility of this happening is more than fine.

Before you solved it I was experimenting with inode, that would work for everything no matter ls or exa, but it is terribly slow using it with find. I may play a bit with it and if I get something fast and reliable I may try a PR.

Thank you for your time on this plugin. It's REALLY great!

[SleepyBag]

It's actually better than that. This works no problem:

Yes, I had misunderstood the mechanism of grep and thought it will match the first ->. But it match the last one. I'm fixing the README.md.

I see that you do the same thing both for ls and for exa. I guess to keep the code simple...

Yes, it is non-trivial to deal with quotes, escaping, and any other special cases in shell scripts. So I just make ls and exa return the same thing: filename without quoting. This introduces ambiguility, but is just fine.