Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

newline "\n" in file names: how to handle them? #433

Closed
marcosrdac opened this issue Jul 27, 2020 · 7 comments
Closed

newline "\n" in file names: how to handle them? #433

marcosrdac opened this issue Jul 27, 2020 · 7 comments
Labels

Comments

@marcosrdac
Copy link

Hi, I'm having some troble managing files that happened to have the escape character '\n'. If I select multiple files (with those problematic ones in selection too) I can't run a script that used "$fs" properly. It breaks the file into two filenames and then my script fails to be run (as those 2 files do not exist, in my example.

I have tried changing the value of ifs via

set ifs='\r'

but everything gets even messier this way. I also tried to set IFS from inside the command I create, but I get no good results too.

Do you have any tips that I could use to solve this problem?

Already grateful!

@gokcehan
Copy link
Owner

gokcehan commented Aug 1, 2020

@marcosrdac Have you tried changing filesep option as well? The default value is \n so filenames are separated by newlines in $fs and $fx.

If you ask me, I would simply drop to shell and handle those files the good old way, and then whine about people using newline characters in filenames.

@marcosrdac
Copy link
Author

Oh, thank you very much @gokcehan, I was naïve thinking that I still remembered these kind of details from your precise documentation. The problem was solved by changing filesep to '\r'.

@yashlala
Copy link

yashlala commented Jul 20, 2023

@gokcehan Apologies for raising an old issue.

I use a command to delete many selected files. My problem when using lf is that I have to be wary when using this command.

set filesep '\n'
cmd trash_all %trash-put -- "$fx"

If one of these files has a newline in it...what have I done? Who have I deleted? I don't know. I don't use filenames with newlines in them. I dearly hope never to -- but if I ever run into one and don't notice, this design makes it very easy to shoot myself in the foot. I cannot trust this command. I will not run it on a visual mode selection, because newline-named files could be hanging around somewhere in the dirs, like landmines.

In a prior issue, you stated that it doesn't make sense to make this functionality newline-compatible when the rest of lf's code doesn't support it. I understand this perspective. To add full support for newline files would mean changing file storage formats, for very little reward.

The more narrow use case of "passing file lists to commands", however, seems to be a lot more well trodden. Most of us have no desire to bookmark, jump to, mark, or list a newline-named file in lf. But what if we want to use a different command to solve our problems outside of lf? Certainly people keep raising issues about this problem.

Let another program take care of these problematic files -- just give lf a way to pass their names to this program. Make lf extensible.

When I pass arguments to a shell script, I automatically get $1, $2, $3, $@. This solves the delimiter issue. It seems like this could be easier to implement. Eg: when spawning the shell, the currently selected files are passed as arguments -- the shell logic will take care of the rest in a platform independent way. This wouldn't complicate the $fx mechanism, and would work exactly how people are used to.

  • Would you be interested in including such a mechanism in lf?
  • If you'd rather not implement it -- would you be willing to accept a PR?
  • If you don't like the idea -- why? What problems do you see? Is there a better way?
  • And if you're not interested in any effort in this direction, please let us know.

@gokcehan
Copy link
Owner

@yashlala Shell command arguments are already in use though. Try this:

cmd say !echo $1
say hello

This was already proposed and discussed in the prior issue you mentioned.

@yashlala
Copy link

Shell command arguments are already in use though. Try this:

cmd say !echo $1
say hello

I'm aware of this functionality, it's done well. But this does not help my use case of mass file removal, because I don't believe it's possible to use this functionality in a mapping.

I'm proposing that when a mapping is run, the currently selected items should be passed to the command.
For example:

cmd trash-all % trash-put -- "$@"
map dw trash-all

Now, dw can delete what I select, without any spacing issues.


Regarding Issue #1114 (which I believe is the issue you mentioned -- please LMK if this isn't it):

I believe the discussion there ended with your (rightly) saying:

the problem with these discussions is that there is never really a concrete
example or usecase so we end up talking in abstract. So ideally you should
propose a technical change with all the required specifications along with an
example in its full and then you need to somehow argue how the proposed
change will make the example move from a non-working state to a working
state.

The use case presented above (file removal) is important to me. I believe making the selected items available $1, $2 available inside mappings will solve this issue, as seen in the example above. Would you be interested in merging a PR to implement this functionality?

@gokcehan
Copy link
Owner

@yashlala Shell command arguments are also available for mappings as well. Try this:

cmd say !echo $1
map dw say hello

So what are we supposed to do with these arguments?

@yashlala
Copy link

Shell command arguments are fine -- I'm proposing passing the currently selection as arguments. Ie:

cmd say !echo $1
map dw say "$@"

Now, when I select entries (via something like map v toggle), I can type dw to delete them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants