termux-app
termux-app copied to clipboard
termux-file-editor does not modify original file but a copy in downloads
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.
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.
I am referring to file editing intent handler hook.
https://wiki.termux.com/wiki/Intents_and_Hooks
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.
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
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)
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 I'm guessing here, but I think it would involve changing Termux's code, specifically TermuxFileReceiverActivity.java
which I linked to earlier.
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.
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?
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'stermux-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
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.