Came up with an even better solution: Base directory /var/tmp

Because think about it: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

| /var/tmp | Temporary files to be preserved between reboots. |

That place is actually all around like /tmp, except that it pays tribute to the only condition making the data set unsuitable for /tmp: It has to survive reboots.

Viewed from all possible angles, there are only advantages placing said data set into /var/tmp:

• It fits the place description well.

• bash script X can check this place and create a sub directory in this place without sudo or deviating from conventions recommending not to create a sub directory for own bash scripts at that place, which are not shipped with the distribution.

mkdir /var/tmp/bash_script_x_logs

• bash script x can save logs there - for each file processed the 1st time of the day - without needing elevated permissions, sudo or root

ls /var/tmp/bash_script_x_logs


• Everyone can access this place, its shareable, enabling collaborative work on processed bash script Y.

Example, imagine there are users A, B and C, either on 1 host or spread across several.

It's 8AM, user C is the 1st one working on bash script Y, analyzing how it is by bash script X.

Bash script X saves the data set of the first run analyzing bash script Y into /var/tmp/bash_script_x_logs.

User works on the file until 11AM, making it more efficient, lets it get the job done with needing 15% less lines for it at 11AM than at the beginning at 8AM.

At 10PM User A continues work on bash script Y, and in parallel analyzes progress with bash script X, analyzing lines, characters, file size, etc.

But as a reference bash script X then uses the data set saved in the morning at 8AM by user C, instead of re-inventing the wheel by generating an own start data set for comparison with later versions of bash script Y, which are still generated at that day.

So, the comparison displayed to anyone running bash script X at 11PM against bash script Y shows progress made from first run of the day at 8AM to 11PM - not just from 10PM to 11PM, or even no comparison, but instead simply just setting a new start data set.

The next day, User B starts to work on bash script Y and analyzes progress by bash script X, 1st run of the day, 1PM. This value will overwrite the value of the day before. So, to be more clear, the data set has not a shelf life of exactly 24h, but just until midnight. After that, the data set may still be there, so, exist even the next day, but that next day with the next run of bash script X against bash script Y it will not be used anymore as a reference value. Instead bash script acts, as if that old data set doesn't exist: It concludes "Oh, there is no data set for bash script Y saved for today, yet! So, I'll change that, and in case there is anything left from yesterday or even more back, like, last week, or 3 days ago, I'll overwrite it!"

Optionally an additional cron job could whip out everything within /var/tmp/bash_script_x_logs/ at 11:59 PM every day of the month, every month, every week day. But if you ask me, that's unnecessary, overload.

That's nice... I like this.

I am developing a small bash script Y, which counts lines, characters and file size of a given bash script X, and stores the results of the 1st run of the day at some place.

When run additional times for bash script X, it's supposed to compare the stored value with the new value retrieval, output what changed and to what percentage. For example "File size: -12%" for bash script X being 12% smaller in file size since 1st run of the day.

So, the stored data of the 1st run is rather short-lived, but is supposed to survive a reboot. It is supposed to have a shelf life of 1 day. So, reboots or shutdown are NOT supposed to set an end to the life of the stored data, but as soon as 24h passed, the next run of bash script Y is supposed to overwrite the old data for bash script X by the new data of bash script X.

What is the best place to put this specific kind of data in accordance with the Linux File Hierarchy Structure or the Filesystem Hierarchy Standard (FHS)?

You see: Said data is kind of semi-short-lived; if it was fully short-lived it would be undone, overwritten with every reboot or shutdown. In that case, there's no question that /tmp/ would be a decent place for this data produced by the script. But in said, a bit more long-lasting case, which is supposed to survive reboots and shutdowns, but not a time window beyond 24h? Where to put that kind of data for a working bash script? I assume /var or /usr/local/… maybe as base directory, and then placing an own sub-directory called 'bash script Y' in it…

  • 1
    Is the data supposed to survive a run of the script? Your setup sounds very much like your script should just overwrite its own data file unconditionally, put that data in a permanent location, and be run daily. Jan 22 at 22:38
  • 7
    hey, please don't add your solution to your question! Jan 23 at 18:07
  • 5
    instead, post it as an answer to your own question (and restore the question to its prior state). That way, people see which solution you chose, and you can select your own answer as the accepted answer. Jan 23 at 18:07

2 Answers 2


If this is data that belongs to a human user, the right place would be $XDG_STATE_HOME, which defaults to $HOME/.local/state, in accordance to the freedesktop XDG specification.

In analogy to that, I'd put temporary daemon data in /usr/local/state – but that wouldn't be FHS-compatible, which says you're supposed to put such state in /var/lib/<yourprogramsname>.


I would do this in two parts:

  1. The core bash script, which makes a new uniquely named temp directory (under a suitable parent) for every run.

  2. A cleanup script (likely invoked by the core bash script AND by cron) which prunes data more than N hours old.

Clever use of invocation parameters to make one source file perform both functions would be the optimization.

  • This doesn't answer the question: which parent directory would be suitable?
    – Bergi
    Jan 23 at 10:36
  • The cleanup script could/should be logrotate, rather than writing (and maintaining) something new. Jan 23 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .