CODEWITHSUNDEEP
clinuxcommand-linetext-editor
Rocco Mancin
Rocco Mancin

Reputation: 80

How to interact with an external text editor in C

I am developing a command line application in C (linux environment) to edit a particular file format. This file format is a plain XML file, which is compressed, then encrypted, then cryptographically signed.

I'd like to offer an option to the user to edit this kind of file in an easy way, without the hassle of manualy extracting the file, editing it, and then compressing, encrypting and signing it.

Ideally, when called, my application should do the following:

  1. Open the encrypted/compressed file and extract it to a temporary location (like /tmp)
  2. Call an external text editor like nano or sublime-text or gedit depending on which is installed and maybe the user preferences. Wait until the user have edited the file and closed the text editor.
  3. Read the modified temporary file and encrypt/compress it, replacing the old encrypted/compressed file

How can I achieve point no. 2?

I thought about calling nano with system() and waiting for it to return, or placing an inotify() on the temp file to know when it is modified by the graphical text editor.

Which solution is better? How can i call the default text editor of the user? Anything that can be done in a better way?

Upvotes: 2

Views: 584

Answers (2)

user6576367
user6576367

Reputation:

Call an external text editor like nano or sublime-text or gedit depending on which is installed and maybe the user preferences. Wait until the user have edited the file and closed the text editor.

Interesting question. One way to open the xml file with the user's default editor is using the xdg-open, but it doesn't give the pid of the application, in which user will edit the file.

You can use xdg-mime query default application/xml to find out the .desktop file of the default editor, but then you have to parse this file to figure out the executable path of the program - this is exactly how xdg-open actually works, in the search_desktop_file() function the line starting with Exec= entry is simply extracted from the *.desktop to call the editor executable and pass the target file as argument... What I am trying to say, is, after you find the editor executable, you can start it, and wait until it's closed, and then check if the file content has been changed. Well, this looks like a lot of unnecessary work...

Instead, you can try a fixed well-known editor, such as gedit, to achieve the desired workflow. You can also provide user a way (i.e. a prompt or config file) to set a default xml editor, i.e. /usr/bin/sublime_text, which then can be used in your programm on next run.

However, the key is here to open an editor that blocks the calling process, until user closes the editor. After the editor is closed, you can simply check if the file has been changed and if so, perform further operations.

To find out, if the file contents have been modified, you can use the stat system call to get the inode change time of the file, before you open the file, and then compare the timestamp value with the current one once it is closed.

i.e.:

stat -c %Z filename

Output: 1558650334

Wrapping up:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void execute_command(char* cmd, char* result) {
  FILE *fp;
  fp = popen(cmd, "r");
  fscanf (fp, "%s" , result);
}

int get_changetime(char* filename) {
  char cmd[4096];
  char output[10];
  sprintf(cmd, "stat -c %%Z %s", filename);
  execute_command(cmd, output);
  return atoi(output);
}

int main() {
  char cmd[4096];
  char* filename = "path/to/xml-file.xml";

  uint ctime = get_changetime(filename);

  sprintf(cmd, "gedit %s", filename);
  execute_command(cmd, NULL);

  if (ctime != get_changetime(filename)) {
      printf("file modified!");
      // do your work here...
  }

  return 0;
}

Upvotes: 0

einpoklum
einpoklum

Reputation: 131525

First, consider not writing an actual application or wrapper yourself, which calls another editor, but rather writing some kind of plugin for some existing editor which is flexible enough to support additional formats and passing its input through decompression.

That's not the only solution, of course, but it might be easier for you.

With your particular approach, you could:

  • Use the EDITOR and/or VISUAL command-line variables (as also pointed out by @KamilCuk) to determine which editor to use.
  • Run the editor as a child process so that you know when it ends execution, rather than having to otherwise communicate with it. Being notified of changes to the file, or even to its opening or closing, is not good enough, since the editor may make changes multiple files, and some editors don't even keep the file open while you work on it in them.
  • Remember to handle the cases of the editor failing to come up; or hanging; or you getting some notification to stop waiting for the editor; etc.

Upvotes: 1

Related Questions