Is there a privacy risk with gedit on Ubuntu?

I am switching from a GUI based password file to a text based one and I intend to encrypt with openssl.

openssl might be employed in a way similar to the following.

The following script might have a name like encryptPw.sh

#!/bin/bash
if [ ! -f pw.txt ] ; then
  echo "pw.txt not found"
  exit 1
fi
openssl aes128 <pw.txt >pw.aes128
if [ -f pw.aes128 ] ; then
  rm pw.txt
  rm --force pw.txt~
else
  echo "failed to create pw.aes128"
fi

The plain text password file might be edited via gedit. This creates a small risk if a person obtains unauthorized access to Ubuntu if the user is absent when logged in or some other way that provides access to the file system. Does gedit leave cache files or temp files after the gedit application is closed?

Aside: I will switch to full disk encryption since 16.04 is nearing end of long term support but in the meanwhile I have an interest in an answer to this gedit question. Even when a machine has full disk encryption it might make sense to continue to use this script because one would not want this file to be plain text in backups. If the backup goes to a cloud server then you have even more reason not to have plain text in backups. Assumption: The backup itself is not encrypted so for example just boot and de-crypt the full disk and execute tar and the tar archive constitutes backup. If the backup is an image copy of an encrypted disk then obviously "plain text risk" does not apply.

Edit: Thanks to the answer and comment below I was able to add rm --force pw.txt~ to the script.

Related script getPw.sh

#!/bin/bash
if [ ! -f pw.aes128 ] ; then
  echo "pw.aes128 not found"
  exit 1
fi
openssl aes128 -d <pw.aes128 >pw.txt

Related script peekPw.sh

#!/bin/bash
if [ ! -f pw.aes128 ] ; then
  echo "pw.aes128 not found"
  exit 1
fi
openssl aes128 -d <pw.aes128 >pw.txt
cat pw.txt
rm pw.txt
rm --force pw.txt~