At a minimum the name needs to signal what the cleanup strategy for the file is. Is it a temporary file that I can remove if I’m not actively using? If so it needs to include the word “tmp” or a variation. If it only might be a temporary file, it should give me clues about how to determine if it in the future (e.g. by including some sort of type and/or project information). If it isn’t a temporary file, and shouldn’t be deleted, it better damn well say what it is so I can remember it in the future.
Then to try and answer the original question: Usually when you feel like the name doesn’t matter it’s a temporary file, I tend to name them “tmppppp” if they’re hand written (adding p’s until I get to an unoccupied name). I tend to use numbers if they’re written by a program.
Here’s an example of a situation where I claim the name of the file truly doesn’t matter:
I have a command called “tmp” which creates a temporary dir in /tmp, then spawns a new shell in that directory, then deletes the directory when that shell exits. In that temp dir, the cleanup strategy is clear; files get cleaned up when I hit ^D. I tend to name my files in that directory some variation of “lol”.
I would clarify this point by saying: “The name matters if anyone might ever see it.”
Your example works as long as there’s no chance that a crash could leave the temporary directory behind, I’d say. But I can imagine a situation where a temporary directory gets left behind unnoticed. Six months later, you’re low on disk space and you wonder what the heck this directory is and if there’s anything important in it. Of course, in your specific example, I would also say that being under /tmp counts as part of its name, and pretty much answers that question with “no”. (Unless I had recently had a very-long-running process die and was hoping to scavenge the partial results from its temp data, but my /tmp is full of directories all named with some variation of “lol” … but that’s a contrived example.)
I would say that if due to an obscure bug and circumstance the directory is no longer deleted after successfully running this code in production for a few months, your colleague who is on call to debug the issue is going to be very happy if you called your file “<executable_name>_shell_spawn_dummy” instead.
This is on my personal laptop. If my personal laptop has a directory in /tmp with a name indicating that it’s from my tmp command, A) it will get removed at the next shutdown, and B) I’ll know that it’s not important.
Not every UNIX-like environment is a “production” environment with coworkers.
In fact, all of the weird replies in this thread makes a lot of sense if all of you are thinking about this in a production server environment. I don’t know why you’d assume that, but if you did, the comment that “there is no situation where the name doesn’t matter” at least makes sense.
True, I assumed a situation where the code is read either by someone else or myself a few months after I wrote it. If it is a simple/local hack, a name might not always matter.
From the fact that the question was posted here I assumed that the OP pictured situations where in programs that are in production the name doesn’t matter, which I tend to disagree with.
In python I just fd = tempfile.mkstemp() for temp files. If other languages have something similar I use it, or alternatively write it. Everything else, the name matters, just like you said.
And I’d even say that files with names that are obviously created with the mkstemp(3) template are explicitly marked as being safe to delete when you find them on your hard drive.
I think if the name doesn’t matter, as the topic says, then by definition it must be a temporary file. As for non-temporary files the name does matter, because you need to be able to find them again.
I’ve had the experience that whenever I created such a file where the name “doesn’t matter”, I ended up stumbling across it some time later and I had no clue what it did and why it was there. I then had to open it and think about why it was there. And don’t get in the habit of deleting files with weird names, next thing you know is you’ve got some data loss or outages on your hand. Give your files names, even if it’s just ThisFileCanSafelyBeDeleted.txt. You won’t regret the additional 2 seconds you spent, it will pay for itself even if you just prevent confusing yourself once in your entire life.
This might speak to the hostility of the architecture I inherited more than anything, but if I saw a file named ‘ThisFileCanSafelyBeDeleted.txt’, the last thing I would do is delete the file.
That said, I do tend to name vmware snapshots something similar – usually something like ‘delete after DD-MON-YYYY - jgf’ so people know who made it, how long I needed it for, and whether it’s safe to delete. Your idea is similar and quite good, maybe if I can break through the gaslighting from my arch I’ll adopt it.
I have so many /tmp/test.go, /tmp/test.ex, /tmp/test.rb files it’s sad. Then they get lost on reboot and I curse myself out, but don’t change for some reason.
One good thing about the name “test” is that it can be typed entirely with the left hand (on a QWERTY keyboard). Depending on the context, this can leave the right hand free to hover over the Enter key or the mouse.
I do this as well. I keep a handful of test.whatever files in $HOME with a large number of accumulated includes and imports. All the includes I need to try something out are ready to go in those files.
/tmp/ or $HOME/tmp or $HOME/trash/ for directories.
I have a personal policy (for files and git branches) to always delete anything I’ve previously named tmp without looking at what was in it any time I try to create a new temp thing in the same location. This ensures that I never work off of a tmp branch for very long or leave anything important in one of these files.
I use ticket numbers also to annotate temporary lines in code I’m working on. It makes things convenient for grep in files and find with temporary file names.
e.g.
void someFunction() {
// TODO: REMOVE: TICKET-123: Temporary logging for stuff
// "TODO" gets flagged in some submission systems and IDEs (like Jetbrains) as a warning when you go to commit.
}
I’ve seen this go wrong too many times to continue using it.
Apple do this, but very few people can read the bug with a given ID including within Apple. It’s most frustrating in their open source components, where you see “// work around rdar://problem/1234567” and have no idea what is being worked around.
three companies I’ve worked at have changed bug tracker, rendering these comments at best difficult to work with and at worst obsolete.
Using the parlance of the times, bug tracker IDs make software difficult to reason about.
Yeah, easy to say (‘speaker’), stands out among other data, easy to type, slightly amusing. I saw it in some code years ago and have done it ever since.
FWIW reminds that often the most significant act of file creation, that of naming/metadata/path/organization … occurs when we’ve the least knowledge of how do so well. And a lot of the time, we may be doing this for something that isn’t intended to persist. Kind of a backwards way that our operating systems are organized as an historical artifact.
The first ridiculous thing that comes to my head, if its my personal computer it will usually involve creative profanities. Usually brings me some joy later on. If i’m feeling uncreative “lol” is usually is suffice.
langhdk - It’s the fairly reliable result of me attempting to write something random. The overwrite confirmation is a reminder to never rely on mental entropy.
I’ve just written a line of code which names an audio file. It only matters that the name is unique, as here I’m using the filesystem as a database. Effectively it’s this:
I use hep, followed by yay. For random text I also use ABBA followed by FLAPPA.
When people are debugging by printing out stuff, I tell them to include some easily recognizable text. There is nothing worse than 10 lines of values and you don’t know which is which… there are enough things to keep in your head when you’re debugging! (And it’s nice to be able to search for it as well.)
I have started telling people to come up with their own random word - that’s an easy way to tell who left some debug somewhere by accident. Examples that sprintg to mind are are “hatt”, “strawberry” and “popcorn” :-)
foo, blah, or some variation of fuckit.EXTENSION if I’m feeling particularly
frustrated. I do have a habit of naming things in anger. “Uh, why
is this git clone named ansible-fucked-gerrit? I’m sure I had a perfectly
good reason for it 6 months ago…”
Reading that list, quite surprised me how few people use “foo”. I had kind of gotten used to non-geeks being vaguely familiar with foo/bar/baz. But, of course, such folks probably don’t think of those words when they aren’t talking to a geek, so on reflection it makes sense that they would name them things like “asdf” or “lol”.
Myself I tend to use “foo” or “x”, depending vaguely on how annoyed I am that I need to use a temporary file.
99 times out of 100: notes, all other times are some variant of the usual metasyntactics: foo, bar, baz, tmp, etc.
EDIT: Had a coworker who named everything he didn’t have a better name for ‘chicken’ – if he had multiple, I think he’d go with other farm animals. That was more for classes than for files though.
The name always matters.
That sounds insightful, but… no. It doesn’t always matter.
To expand on this:
At a minimum the name needs to signal what the cleanup strategy for the file is. Is it a temporary file that I can remove if I’m not actively using? If so it needs to include the word “tmp” or a variation. If it only might be a temporary file, it should give me clues about how to determine if it in the future (e.g. by including some sort of type and/or project information). If it isn’t a temporary file, and shouldn’t be deleted, it better damn well say what it is so I can remember it in the future.
Then to try and answer the original question: Usually when you feel like the name doesn’t matter it’s a temporary file, I tend to name them “tmppppp” if they’re hand written (adding p’s until I get to an unoccupied name). I tend to use numbers if they’re written by a program.
Here’s an example of a situation where I claim the name of the file truly doesn’t matter:
I have a command called “tmp” which creates a temporary dir in /tmp, then spawns a new shell in that directory, then deletes the directory when that shell exits. In that temp dir, the cleanup strategy is clear; files get cleaned up when I hit ^D. I tend to name my files in that directory some variation of “lol”.
I would clarify this point by saying: “The name matters if anyone might ever see it.”
Your example works as long as there’s no chance that a crash could leave the temporary directory behind, I’d say. But I can imagine a situation where a temporary directory gets left behind unnoticed. Six months later, you’re low on disk space and you wonder what the heck this directory is and if there’s anything important in it. Of course, in your specific example, I would also say that being under /tmp counts as part of its name, and pretty much answers that question with “no”. (Unless I had recently had a very-long-running process die and was hoping to scavenge the partial results from its temp data, but my /tmp is full of directories all named with some variation of “lol” … but that’s a contrived example.)
I would say that if due to an obscure bug and circumstance the directory is no longer deleted after successfully running this code in production for a few months, your colleague who is on call to debug the issue is going to be very happy if you called your file “<executable_name>_shell_spawn_dummy” instead.
This is on my personal laptop. If my personal laptop has a directory in /tmp with a name indicating that it’s from my
tmpcommand, A) it will get removed at the next shutdown, and B) I’ll know that it’s not important.Not every UNIX-like environment is a “production” environment with coworkers.
In fact, all of the weird replies in this thread makes a lot of sense if all of you are thinking about this in a production server environment. I don’t know why you’d assume that, but if you did, the comment that “there is no situation where the name doesn’t matter” at least makes sense.
True, I assumed a situation where the code is read either by someone else or myself a few months after I wrote it. If it is a simple/local hack, a name might not always matter.
From the fact that the question was posted here I assumed that the OP pictured situations where in programs that are in production the name doesn’t matter, which I tend to disagree with.
In python I just
fd = tempfile.mkstemp()for temp files. If other languages have something similar I use it, or alternatively write it. Everything else, the name matters, just like you said.And I’d even say that files with names that are obviously created with the
mkstemp(3)template are explicitly marked as being safe to delete when you find them on your hard drive.agreed. Otherwise they were not temporary files and should never have been created with mkstemp()
I think if the name doesn’t matter, as the topic says, then by definition it must be a temporary file. As for non-temporary files the name does matter, because you need to be able to find them again.
foo
Same here: foo, bar, baz, bat, quux
fizz, buzz, whizz, bang
Yup first foo, then bar, spam, eggs
If I get to spam, I move to a naming a system with more semantic content.
aThis, and its variants
a.py,b.txt, …I’ve had the experience that whenever I created such a file where the name “doesn’t matter”, I ended up stumbling across it some time later and I had no clue what it did and why it was there. I then had to open it and think about why it was there. And don’t get in the habit of deleting files with weird names, next thing you know is you’ve got some data loss or outages on your hand. Give your files names, even if it’s just
ThisFileCanSafelyBeDeleted.txt. You won’t regret the additional 2 seconds you spent, it will pay for itself even if you just prevent confusing yourself once in your entire life.This might speak to the hostility of the architecture I inherited more than anything, but if I saw a file named ‘ThisFileCanSafelyBeDeleted.txt’, the last thing I would do is delete the file.
That said, I do tend to name vmware snapshots something similar – usually something like ‘delete after DD-MON-YYYY - jgf’ so people know who made it, how long I needed it for, and whether it’s safe to delete. Your idea is similar and quite good, maybe if I can break through the gaslighting from my arch I’ll adopt it.
I usually make
tmp/in my working directory if I need it, then name files in there whatever I want.Unfortunately in college I thought it was funny to name my scratch files
loldongsand the habit has stuck. I’m not proud.xI also use
x, it just feels rightasdf, or if one already exists with that name and the same extension,asdfasdfYes, or some variation, like asasasdf.txt or asasasasaa.org
poop
test.{ext}I have so many /tmp/test.go, /tmp/test.ex, /tmp/test.rb files it’s sad. Then they get lost on reboot and I curse myself out, but don’t change for some reason.
One good thing about the name “test” is that it can be typed entirely with the left hand (on a QWERTY keyboard). Depending on the context, this can leave the right hand free to hover over the Enter key or the mouse.
Always some variation of
test! Unless I’m feeling particularly lazy OR there’s anothertestin that directory and I don’t want to delete it. Thent.Anything with those names is always fair game for deletion, and in fact probably won’t be tolerated next time Future Me runs an
lscommand.I do this as well. I keep a handful of test.whatever files in $HOME with a large number of accumulated includes and imports. All the includes I need to try something out are ready to go in those files.
Temp files that I can delete without looking at them begin with “,”
rm ,*”.Temp files that I should look at before deleting begin with “_”, and these usually have more meaningful names.
I like this convention. It’s reminiscent of
.for hidden files. 10/10./tmp/ or $HOME/tmp or $HOME/trash/ for directories.
I have a personal policy (for files and git branches) to always delete anything I’ve previously named tmp without looking at what was in it any time I try to create a new temp thing in the same location. This ensures that I never work off of a tmp branch for very long or leave anything important in one of these files.
lolasht— theasdfof the Workman layout.t
deleteme(the Jira ticket I’m working on).txt
I use ticket numbers also to annotate temporary lines in code I’m working on. It makes things convenient for
grepin files andfindwith temporary file names.e.g.
This is the way. Google even has a lint that TODO comments must have the bug number attached.
I’ve seen this go wrong too many times to continue using it.
Using the parlance of the times, bug tracker IDs make software difficult to reason about.
“temp”
Temporary files and directories are always
temp. If that’s taken I delete it without looking and make a new one.Command output is redirected to
outoroutput. If I need to compare diffs of output then itsaandbwithabeing the one that comes first temporally.Pretty much anything else gets a real name. Hasn’t failed me so far.
x.whatever_ext
For me it’s blah or spqr
Hail Caesar
spqr?
Yeah, easy to say (‘speaker’), stands out among other data, easy to type, slightly amusing. I saw it in some code years ago and have done it ever since.
lala.c,lala.py,doit.sh, …I’ve written my fair share of
crap.cfiles to test things.I usually bash my keyboard. The resulting filename could be, for example:
wegin4g0weg.png. After a while, my folder is full of such files.When do I clean the folder up? When I bash my keyboard and then the rename fails because the file already exists.
:-)
foo, bar, baz, quux, a, b, c, x, y, z, doit (for scripts)
You’d probably like https://en.wikipedia.org/wiki/Metasyntactic_variable
Often a greeting:
sup,oi,helloIf I’m just storing a result:
>outIf I’m naming a file while showing a teammate how something works:
exampleBut you can’t go wrong with
foo.1
“temp”, then there’s never any doubt when you rediscover it in future that it can be disposed of.
test,DO_NOT_DELETE,thing.txtFWIW reminds that often the most significant act of file creation, that of naming/metadata/path/organization … occurs when we’ve the least knowledge of how do so well. And a lot of the time, we may be doing this for something that isn’t intended to persist. Kind of a backwards way that our operating systems are organized as an historical artifact.
all of the above
fuck.https://en.wikipedia.org/wiki/Metasyntactic_variable
If it’s not
foo, it’sout.txt(or maybe some other extension).foo, bar, t, u, v…, 1, 2, 3 …
The first ridiculous thing that comes to my head, if its my personal computer it will usually involve creative profanities. Usually brings me some joy later on. If i’m feeling uncreative “lol” is usually is suffice.
Scratch or spike are my normal names for something temporary
hey, followed bythere_1,_2etc. Always sorts to the top, and easy to delete.The followings are the fallbacks:
Guid.NewGuid().ToString()langhdk- It’s the fairly reliable result of me attempting to write something random. The overwrite confirmation is a reminder to never rely on mental entropy.shabba
I’ve just written a line of code which names an audio file. It only matters that the name is unique, as here I’m using the filesystem as a database. Effectively it’s this:
If I’m in a shell and have some output I want to save and look at (probably with Vim) then
.ais my usual choice“Poop”, “stuff”, or “blah” are some of my reflexive choices.
I use
hep, followed byyay. For random text I also useABBAfollowed byFLAPPA.When people are debugging by printing out stuff, I tell them to include some easily recognizable text. There is nothing worse than 10 lines of values and you don’t know which is which… there are enough things to keep in your head when you’re debugging! (And it’s nice to be able to search for it as well.)
I have started telling people to come up with their own random word - that’s an easy way to tell who left some debug somewhere by accident. Examples that sprintg to mind are are “hatt”, “strawberry” and “popcorn” :-)
foo.txtlol
xif I’m going to be deleting it shortly;simon-deletemeif it might stick around for a while.I just stick it in /tmp, and let the system delete it on restart.
t
Plus an extension if relevant e.g. t.txt.
bla
foo, bar, baz, lala, lili, lulu.* In that order.
foo, blah, or some variation of fuckit.EXTENSION if I’m feeling particularly frustrated. I do have a habit of naming things in anger. “Uh, why is this git clone named ansible-fucked-gerrit? I’m sure I had a perfectly good reason for it 6 months ago…”
bikeshedding in action
scratchSpot the Emacs user :-)
IntelliJ has scratch files too.
I send scratch data to /tmp/a
plopSomething profane so I remember to delete it
test.
Reading that list, quite surprised me how few people use “foo”. I had kind of gotten used to non-geeks being vaguely familiar with foo/bar/baz. But, of course, such folks probably don’t think of those words when they aren’t talking to a geek, so on reflection it makes sense that they would name them things like “asdf” or “lol”.
Myself I tend to use “foo” or “x”, depending vaguely on how annoyed I am that I need to use a temporary file.
I like “junk”, that way it’s clear to others it’s unimportant.
omg, wtf and lol are my favorites.
What’s in the file?
99 times out of 100:
notes, all other times are some variant of the usual metasyntactics: foo, bar, baz, tmp, etc.EDIT: Had a coworker who named everything he didn’t have a better name for ‘chicken’ – if he had multiple, I think he’d go with other farm animals. That was more for classes than for files though.
I just name it whatever this produces: