lf: Add support for linefeed `\n` character in paths saved to `~/.local/share/lf/files` (paths delimiter bug)
Some time ago I was working with ~/.local/share/lf/files file and after some edge cases I quickly figured out that right now file/dir names are stored unreliably. The easiest example of this is when there is a linefeed \n symbol in the name: it will be saved in the “file” as 2 lines, e.g., as 2 names. And you really can’t have 1 delimiter, as any character can be in path (because Linux support all Unicode characters).
Right now I was working with opener.sh for cmd open $.../opener.sh and because of POSIX (I like to make as many of my scripts as portable as possible) shell I stumped into the same problem with Unicode names and delimiter (mainly because there are no arrays in POSIX shell). Luckily, I was able to find some kind of portable solution: using base64 encoder/decoder from coreutils (which is not POSIX, but a lot of distros are GNU/Linux).
The point is that using any simple and fast encoding you can greatly limit the output charset and therefore choose any delimiter you like (even the same linefeed). Since I’ve limited myself to mostly POSIX shellscript I have limited encoders (or I can make my own), but you are making the program in Go and I think your options are far richer than mine. Hence, the implementation of this enhancement should be pretty straightforward and not as bulky as mine, IMO.
So, basically my idea is to put encoded path echo "$unicode_path" | base64 into the same ~/.local/share/lf/files file and delimit each encoded path with a linefeed \n (same as now). And when you need to paste selected files/dirs you just use echo "$encoded_path" | base64 --decode and then process each Unicode path separately in Go (or shell or whatever).
The only downgrade will be in user-friendlyness because after encoding, the “file” will be “ciphered” for the end user. And to overcome this problem, you will have to add a note in the manual for how to get the original (decoded) data from the “file” (or at least which steps are performed to create the “file”).
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 35 (5 by maintainers)
This issue comes up from time to time and there was even a hot discussion about this in the past but in the end I still think it is more useful to keep things simple. Part of the problem that I haven’t seen in this discussion is that environment variables can not contain
\0characters as far as I remember. We also don’t have a proper way to display filenames with newlines in the tui I think. If there will remain some parts of the program that does not handle newlines properly, I don’t see much gain for making a specific part of the program newline compatible. I guess the recommended way is just to handle the filenames with newlines by dropping to the shell and then complain to the person who sent you the file afterwards.