banner
Previous Page
PCLinuxOS Magazine
PCLinuxOS
Article List
Disclaimer
Next Page

Delete Lines From A Text File Easily & Quickly


by Paul Arnote (parnote)


Recently (as in towards the end of February, so it was quite recent), I went to update what I call my “travel” laptop. It’s a small Lenovo ThinkPad X230. I used to carry it in my backpack when I was still working.

That laptop had a PCLinuxOS Xfce installation that had served me very well since its first installation about five or more years before. When I first installed PCLinuxOS on the computer, I just accepted all of the “default” values of the old installer. That included a “default” size for the root directory of only 20 GiB.

I thought it would be adequate.

I was wrong.

I accepted those default values of the old installer because of the “smallish” SSD that the travel laptop had in it. It was only a 128 GiB SSD, which I viewed as being much smaller than I felt comfortable using. I was always fearful of quickly filling up that SSD. With all of my “other” installs of PCLinuxOS, I always made my root partition 30 GiB or 40 GiB.


Frustration
Image by Temel from Pixabay

One day, while I was still working (I retired at the end of 2022), I went to update my travel laptop while I was at work. I got the dreaded message that the root partition was full.

So, I got to work on removing extra “stuff” that I really didn’t need on my travel laptop. I managed to free up enough space to allow the updates to complete.

And then, I forgot all about that incident … until it happened again in late February. I had done other subsequent updates on the computer without incident, so that caused the incident at work to drift further back in my mind. Having previously removed everything unnecessary from the computer during the 2022 incident, there literally was nothing more left to remove to make more room. Irritated, I dived in, and ended up borking my install on that SSD.

Now, it’s no secret that I’ve been sitting in this “editor’s” chair for nearly 16 years. Over those years, I’ve written about virtually all aspects of PCLinuxOS. I’m also no noob when it comes to installing PCLinuxOS, having done so many, many times before. Not only on my own computers either, but also on the computers of friends and family. So, suffice it to say that I know my way around installing PCLinuxOS pretty well.

Now, I had planned on installing a new SSD into this travel laptop for nearly as long as I’ve had it. But, for some unknown reason (yep, unknown even to me), I threw all of that accumulated knowledge out of the window and made the most egregious of rookie mistakes. I just plunged ahead, acting like a total noob.

Let me remind you of a couple of things. First, backup your files before trying to resize your partitions. Now, this travel laptop didn’t have anything stored on it that I couldn’t live without, so I skipped that step. Trust me when I tell you that the risk of data loss is VERY real when you try to resize your partitions. And that step is not what ultimately ruined my attempts. Nope. The second thing you need to remember is that you should ONLY ever try to redo your partitions (via GParted) from a Live session … which I failed to do. In the end, the SDD’s file system ended up as one big blubbering mess. (Never fear. I’ll reformat the SSD and find another use for it.)


Terminal
Image by OpenClipart-Vectors from Pixabay

So, I ended up forcing the issue about changing the smallish SSD to a larger one. I should have done it long ago, like when I first acquired this laptop. I tend to buy SATA3 SSDs when I see them on sale for a good price (and when I have the funds to do so), so I have several “lying in wait.” I grabbed up a 512 GiB SSD, and swapped it out with the 128 GiB SSD. That part was super easy.

I set up a 200 MiB partition for EFI boot (this laptop has EFI, but is old enough to NOT have (in)Secure Boot), a 50 GiB root partition on the new SSD, a 8 GiB swap partition, and assigned the “rest” of the space on the SSD to my /home partition. Installation was fairly straight forward, minus a couple of small hiccups that were quickly overcome/resolved.

<action>
    <icon>terminal</icon>
    <name>Open Terminal</name>
    <submenu></submenu>
    <unique-id>1694383311350259-1</unique-id>
    <command>exo-open --working-directory %f --launch TerminalEmulator</command>
    <description>Open Terminal window here</description>
    <range></range>
    <patterns>*</patterns>
    <directories/>
</action>
<action>
    <icon>gksu-root-terminal</icon>
    <name>Open Root Terminal</name>
    <submenu></submenu>
    <unique-id>1694383311350271-2</unique-id>
    <command>gksu xfce4-terminal</command>
    <description>Open Root Terminal window here</description>
    <range></range>
    <patterns>*</patterns>
    <directories/>
</action>
Snippet from my uca.xml file

It’s also no secret that I’m a big Xfce fan. I also have a LOT of Thunar Custom Actions that I like to have installed on ALL of my computers running Xfce. Now, the uca.xml file is where Thunar stores all of the magic that allows the Thunar Custom Actions to work. Some time ago, probably starting around Xfce 4.14 (I forget exactly when), the Xfce developers “inserted” another field into the data fields of each Thunar Custom Action. That data field is called . For the life of me, even after searching for what seems like an eternity, I cannot see or find the purpose of this entry. However, I do know that with that data field left intact in the uca.xml file, you also cannot transfer your uca.xml file to another Xfce installation … unless you take the time to remove that line from each Thunar Custom Action you have defined.

I have a very definite set of files that I transfer between my computers when I do an installation on a “new” computer (new to me, anyway). I transfer my magazine layout files (vitally important to me), my custom bash scripts, and – without fail – my uca.xml file. It would literally take me DAYS to transfer them all by hand. So, quite by accident, I discovered some years ago that if I went through the uca.xml file and deleted the line from each defined Thunar Custom Action, it worked as it should. Thunar will recreate that line automagically if it’s not present. Thus, it allows me to transfer my uca.xml file between my various computers running PCLinuxOS Xfce.

So, I set out to transfer my uca.xml file from my main computer to my travel laptop. That means that I opened the uca.xml file editor, and manually deleted all of the lines. That whole process took about 15 minutes, which while WAY faster than trying to enter each Thunar Custom Action by hand, one at a time, it is/was still an arduous process. As I’m doing this, one thought kept going through my mind. Do you want to guess what that thought was? Yep. You guessed it: “There has to be a faster way to do this.”


A Bash Script To The Rescue

So, that’s when I decided to create a bash script to do this tedious task for me, and that’s what this article is really about.

If I wanted to create the bash script to ONLY remove the line, that would have been extremely simple (once I figured out how to do it). In fact, it would have been so simple that I wouldn’t even need a bash script. I could just put in the necessary command alone as the parameter for the Thunar Custom Action. But I created a bash script that allows you to use it on ANY text file (plain text … not a file from a word processor). Who knows? There might be times when such a tool comes in handy to remove annoying lines of text from other text files. So, I decided to head in that direction, instead.

I call my script “strip-line.sh.” Below is the entirety of that script. The whole bash script is 471 bytes in size, so I’m not including a link to download it. As small as it is, it should take you all of five minutes (or less) to type it in.

#!/bin/bash


# This script will remove any line from a text file with the specified text in it.
#
# by Paul Arnote
# Published in The PCLinuxOS Magazine, April 2025 issue
# This script is released under a GPL 2.0 (or higher) license
#
# This script takes a single text file filename as its sole parameter.


textfile=$(zenity --entry --title="Text File Line Deleter" --text="Enter the text to remove:")
    if [ $? == 1 ]; then
    exit
    fi
sed -i '/'$textfile'/d' $1

Like many of my other scripts, this one can be run from the command line, or from a Thunar Custom Action. If you run it from the command line, you only need to provide the name of the text file you want to delete lines from.

I keep all of my bash scripts in a directory in my /home partition, called bin. That /home/bin directory is in my path, so they can be found easily by the operating system without having to provide a full path to the bash scripts when I want/need to run them.

As with all bash scripts, the first line contains the typical bash “shebang.” That is followed by seven lines of comments.

The line that starts with “textfile” launches a Zenity dialog box where you can specify what text you want to search for. In my case with the uca.xml file, I want to find every occurrence of the lines, and delete them. The “if” statement causes the script and Zenity dialog box to exit cleanly if the “Cancel” button is selected in the dialog box.

The last line, which starts with “sed” is where all of the “magic” occurs. The “-i” command line parameter tells sed to do inline editing, which is bash-speak for editing the file without physically viewing it (as you normally would be able to do if you opened the text file in a text editor). The text entered into the Zenity dialog box is searched for ($textfile), and if the specified text is found, that entire line is deleted (the “/d” parameter).

In my particular use case, all I have to do is type “unique-id” into the Zenity dialog box. When I click on the “OK” button, every line that contains “unique-id” will be deleted from the text file (and XML files are nothing more than a specially formatted text file).

I will tell you that this script works PERFECTLY. It takes a task that usually takes me 15 minutes to accomplish manually with a text editor, and completes it in under five seconds. If I had this script several years ago, it would have (cumulatively) saved me HOURS of tedious work.


Using This Script As A Thunar Custom Action

As I mentioned earlier, I created this bash script to run either from the command line, or as a Thunar Custom Action.


Thunar Add Action

So, let's add this to our Thunar Custom Actions. First, in Thunar, go to “Edit > Configure custom actions…”. The dialog box that looks something like the image above should appear. To create a new Thunar Custom Action, simply click your mouse on the “+” button, outlined in the image above with a red box.


Action Options 1


Action Options 2

In the first of the two images, give your Thunar Custom Action a name and a description. I also choose to store my Thunar Custom Action in a submenu I’ve created, called “File Tools.” The command will be strip-line.sh %f. The “%f” tells Thunar to execute the script on the file you right-clicked on. It passes the full path and filename to the bash script to work on. (Note: %n also works fine (instead of %f), except it only passes the filename, without any path information.)

Under the second tab (second image), place a checkmark in the checkbox next to “Text Files.” Leave the “File Pattern” and “Range” fields with their default values of “*”. Once you’ve done this, click on the “OK” button at the top of the dialog window. Your new Thunar Custom Action will appear as the last item in your list of custom actions, or (if you’ve done as I have, and placed it in a submenu), at the end of the list of Thunar Custom Actions in that submenu.


Summary

Although this is a relatively simple bash script, it streamlines a very tedious task by finding every occurrence of the indicated text, and deleting the entire line containing that text from the text file. While my use case is unique and focused, I’ve tried to make this script flexible enough to be of use for other situations where there is repetitive text/lines that need to be removed from other text files.



Previous Page              Top              Next Page