termux-app icon indicating copy to clipboard operation
termux-app copied to clipboard

termux-file-editor does not modify original file but a copy in downloads

Open rajeevn1 opened this issue 6 years ago • 11 comments

When I choose another file editor I am able to modify the file being opened but termux created a copy in downloads and invokes the editor on the copy.

Can termux to used to modify the source file like other android text editors.

rajeevn1 avatar Jul 08 '18 00:07 rajeevn1

I don't understand the question really... need more info. But if I get the gist of what you're referring to, you are trying to edit a file in /sdcard/Download with termux? Termux starts in directory path /data/data/com.termux/files/home This is totally different than files on device sdcard (internal storage, not external sdcard.)

Maybe change directory to the path of the file you want to edit? Like: cd /sdcard/Download ; ls -a (find file to edit) ; nano filetoedit.txt

The answer is yes, termux can edit source code/txt files like (but better than IMO) other text editors. Nano or vi are good tmux editors.

setuidroot avatar Jul 09 '18 18:07 setuidroot

I am referring to file editing intent handler hook.

https://wiki.termux.com/wiki/Intents_and_Hooks

rajeevn1 avatar Jul 09 '18 21:07 rajeevn1

I have exactly the same issue.

As described in https://wiki.termux.com/wiki/Intents_and_Hooks, i made mkdir ~/bin && ln -s $PREFIX/bin/nvim ~/bin/termux-file-editor.

Now, when tapping on a text file, I have the option to open the file with termux. But instead of editing the selected file, termux will copy it to ~/downloads, and open that file.

Notice that from the cli I'm able to open, for example, files on the sdcard, so it should not be a permission issue.

fekir avatar Feb 21 '19 06:02 fekir

Is there a way to pass the file path to termux as well? if so, an script could be written in termux-file-editor such that after editing, it replaces the $FILE_PATH with ~/downloads/filename

m-yosefpor avatar Apr 06 '19 04:04 m-yosefpor

Relevant code is located here. When an app "shares" a file or URL to Termux it sends an Intent (a way for different apps/activities to communicate) with information about the file(s) that were shared. The problem seems to be that if I share files to Termux using Generic File Manager App A and you share files using Generic File Manager App B, the intents that these apps send can be very different. Intents that are sent by a particular app can be viewed with the Intent Intercept app from Fdroid.

This is where Termux starts parsing an intent that was sent to it. That's where it parses the content and decides if it's a URL (to be used with termux-url-opener) or a file (to be used with termux-file-opener).

One (probably naive) approach could be to take an intent and save the whole thing as a text file in $TMPDIR Then the user's termux-file-editor script could parse that file with grep/sed/awk or other tool of their choice and open the file in place with e.g. vim/emacs (assuming the file isn't located in an app's private storage). This puts the responsibility of parsing the intent correctly on the user, but it could allow for modifying a file in-place, rather than a copy of the file in ~/downloads (the current situation)

sudomain avatar Jul 16 '20 20:07 sudomain

Great. But is there already a way to save the intent as a text file in $TMPDIR? or should it be patched in termux code? @sudomain

m-yosefpor avatar Jul 16 '20 21:07 m-yosefpor

@m-yosefpor I'm guessing here, but I think it would involve changing Termux's code, specifically TermuxFileReceiverActivity.java which I linked to earlier.

sudomain avatar Jul 17 '20 02:07 sudomain

Is it that case that the issue Termux has here (as opposed to other file editors that will automatically edit in-place) is that Termux needs to decide whether to edit the file or open it as a url?

It seems that @rajeevn1's issue wasn't that termux-file-editor wasn't being triggered correctly, it was just that it was being passed a copy of the file rather than the path to the file itself. What changes might be needed to adjust this behaviour?

Or is the issue the parsing of a file path out of the various formats of intents termux might receive? In which case, how do other file editors as mentioned by OP get around this to behave correctly?

I think this is an important issue to solve, because it prevents smooth use of Termux (and hence vim, nano, neovim etc) as a file editor, which is otherwise a significant Termux benefit.

BlueDrink9 avatar May 04 '21 23:05 BlueDrink9

My understanding of the code is likely to be limited, but it seems to save a new file when the intent contains a file. Would it be possible to pass the file path directly to the editor as an argument, instead?

BlueDrink9 avatar May 04 '21 23:05 BlueDrink9

The current behavior is very limiting. Please allow disabling this unnecessary copy semantic and invoke script with original file path(s) as arguments if shared storage access has been granted. Not much benefit from having scripting environment if there's no way to interact with it from outside.

One (probably naive) approach could be to take an intent and save the whole thing as a text file in $TMPDIR Then the user's termux-file-editor script could parse that file

Nah there is already to much work to be done by the user e.g. to have multiple actions for shared files requires scripting the interaction manually there

cunlem avatar Feb 06 '22 00:02 cunlem

if shared storage access has been granted

Storage access isn't even needed. Access for the shared file is automatically granted through SAF by the system, when the shared file is opened with termux. The shared file can even be overwritten or even deleted in-place without WRITE_EXTERNAL_STORAGE or any other permissions. Hope #2658 fixes this.

Blocked avatar Aug 29 '22 10:08 Blocked