xclip to the rescue? How I wish . . .

I find the blogging platform I've been using for this blog to be horrendous. First, I don't want to have to log into a website to write articles: I'd rather type them on my computer, usually using my favored command-line text editor nano.

I was iniatially enthused to discover that blogspot/blogger (the host for this blog) offered the possibility of e-mailing posts. Esssentially, you add a custom word to an e-mail address they provide, and you can use that to send posts directly to your blog (subject line becomes the blog posting's title). Great, I thought, I can type posts on my computer and send them to my blog.

But my enthusiasm was shortlived. Initial tests indicated that the blogging platform was inserting a bunch of extraneous html tags into postings I'd send like that. No problem, I thought, I'll just write my posts with html, tags pre-inserted. Tests using that method indicated that the platform was continuing to insert those extraneous tags. See the graphic below for an indication of how the file looks in html editing view on blogger's site (all the &gt &lt &#39 and <br> were added by their system, not by me):

So I was left with a dilemma: how can I more conveniently, according to my preferred practices, continue blogging here? Researching the matter revealed the xclip utility, which appeared to be a good workaround for helping deal with the constraints involved in continuing to blog on this platform.

I discovered that, after I save the posting I've written under nano, I can simply cat the file into the system's clipboard by running a command like cat myfile.txt | xclip (see the LATER EDIT note added at the very end of this post for the corrected invocation for the blogger site) and from there paste it into the platform's editor interface by placing my cursor there and clicking the middle mouse button. Granted, it's pretty much the same as using a graphical text editor like leafpad and hitting ctrl-a to highlight the whole of the file, ctrl-c to copy the highlighted text to the clipboard, then ctrl-v after placing the cursor into the platform's editor interface. Not ideal, since I would much prefer if the e-mailing method would work as I had hoped by just importing the text as written in the file, but it's an acceptable (at least for now) workaround.

Perhaps more to come later, if I manage to make improvements or to figure out some heretofore overlooked factor.

Afterthought: I tried to paste this post into the blogger editing interface using xclip and it didn't work. Nothing would paste. So I had to paste the text into leafpad, then do the ctrl-a, ctrl-c, ctrl-v trick to be able to paste it here. So I changed the exclamation sign I had initially placed at the end of the title to a question mark, since it may not provide the solution after all. Sigh.

LATER EDIT: IMPORTANT! I've discovered that the way I can paste text into blogger using xclip is by running it with a couple of switches, as follows: cat myfile.txt | xclip -selection clipboard: having done that, I can then place the cursor in blogger's html editor and hit ctrl-v and the text from the file will paste into the editor as intended.

TeX/LaTeX: tex to txt

Since a .tex file is already essentially compatible with all text editors, you may be wondering why anyone would need to do any sort of conversion to .txt format. I would also have wondered at why such a task would need to be done--that is, until I ran into the need myself.

But I did run into such a need. The issue was that I had a nicely formatted .tex document--an article, actually, that I had translated with the aid of my computer, into a foreign language. I had one fairly competent translator check the machine translation over and do some corrections and thought I was ready to go. Then, another translator had a look and offered to do further improvements, to which I gladly assented. This is where I ran into a problem with the nicely-formatted file.

This translator, although quite well-qualified and fairly capable in matters technical, was nonetheless not at all familiar with Tex/LaTeX formatting. So I couldn't really give him the document in the most optimum format for me (.tex) for correcting. And at the same time getting from him the corrected text in a format like .pdf or .doc would further complicate my task of getting it back to its nicely-formatted .tex state. Thus, I decided that .txt would be the most neutral format to use for providing the translator with the computer-translated text for further revision. But how to do that?

Well, I had already created a pdf of the document, so I had that to work from. Using sed or awk to strip out all the TeX formatting codes would be an option for someone far better versed in those utilities that I am. But even that might prove a fairly involved and time-consuming task.

Some on-line searching revealed another possible solution: it involved using the utility pdftotext. It seemed worth a try.

Sure enough, running pdftotext file.pdf file.txt actually gave quite good results. There were a few anomalies I needed to clean up, but they were actually fairly few in number. I'd say the whole process took about 15 minutes total, after which, I had a .txt version of this 5k-word file that I could submit to the translator.

So, in the unlikely event that you may need to convert your .tex file to .txt, I can recommend the routine of first converting it to .pdf, then the resulting file to .txt. I should probably mention that this file didn't contain graphics, a table, or any sort of chart. So I can't vouch for how it would work on files containing comparatively more complex elements such as that. So, probably the less complex the document is, the more successfully it will convert using this method. So, there you have it, a method for converting .tex to .pdf to .txt

A motd project

Long time no post. Well, life precludes various tech experimentation and hoped-for successes sometimes.

But I do have a couple of projects to describe. One involves a back-up routine I developed a few years ago. I have doubts that one will be of much interest to most in that it was developed specifically for the non-uefi machines I tend to use and target the paltry-sized hard drives (120 gb and less) and comparativeley meager installations I favor. But it's fairly straightforward and, to my somewhat unrefined tech sensibilities, clever. The other is yet simpler and is the one I'll be describing in this post.

I refer to it as a motd (message of the day) project/routine because I want the system to provide me with certain information when I log in. My implementation differs a bit in that it also even provides this information whenever I start a new bash session.

The information I want the system to provide me is twofold: 1) reminder of when I last backed up the system, and 2) on some of my machines, a reminder of when I last updated the operating system. In most cases what I'll need reminding about is only number 1), since I'm regularly using these systems and do operating system updates on these rolling-release (Arch and Void) systems every 1-2 weeks.

On other systems, however, such as my laptop, I'll need reminding about number 2) as well. That machine, and the VPS I use, are systems I am only occassionally logged into. So knowing when was the last operating system update is quite important on those.

So my solution involves creating the files motd-backup.txt and motd-update.txt in my home directory and writing target information to them. Since I haven't scripted the back-up routine, that has to be done manually by running something like echo "++last system back up done on $(date)++" >/home/user/motd-backup.txt after I've finished running my back-up routine. That's something I'll be adding to the notes I keep as a reminder about how to use that routine.

As for the operating system updates, I've semi-automated those. I run a script at certain intervals that opens a bash session and queries whether I'd like to do a system update: a response in the positive triggers the update. I've added to that a command that runs after a successful update and writes information to ~/motd-update.txt. It looks as follows: echo "++last update $(cat /var/log/pacman.log | tail -1 | cut -c2-11)++" >/home/user/motd-update.txt

Arch'ers will understand that what's happening is that the pacman log file is being queried and information from the final entry is being excerpted and cat'ed (is this a misuse of cat?) into the motd-update.txt file. It has worked well in my testing and should suffice for the purpose.

The final piece of the puzzle is getting the information to display. I want it to be available during my day-to-day computer usage and not in a file stored somewhere on the system. Experience has indicated that I am likely to forget about such a file and so become remiss in my system administration responsibilites.

Since I'm regularly using a terminal, I decided a good place to cause that information to be auto-displayed with regularity would be make it part of the process of starting terminal sessions. So I put the following line at the end of my .bashrc: cat ~/motd-update.txt && cat ~/motd-backup.txt

And that addressesd my issue. Every time I log into the system or start a new terminal, that information appears.

As I write this, I begin to think of alternatives. For example, I could use something like Xmessage and cause a pop-up to appear at regular intervals--say once weekly--that would contain such information. I'm sure other options like zenity could be fairly easily configured to do the same. Or perhaps making a .png out of the information as I wrote about a few years ago (https://audaciousamateur.blogspot.com/2020/04/another-imagemagick-trick-txt-to-png.html) and using cron to pop up feh or some image-displaying utility that shows the information in bright text on a dark background. That could be more disruptive but might be more effective.

In any case, what are your ideas for displaying important information like that? Auto-generated e-mails, for example? There are lots of possibilities. The ways to skin this cat (pun intended) are numerous.