run a tail -n10 doc.txt and observe the last line of output matches the final line of that text file.
use any “non-Mac native” editor (like Emacs or pico) to add a final line to that doc and repeat step 1 → you’ll see the same output as you saw in step 1. In order to see in the tail output that final line you just added to the text document, you obviously need to save the file first, duh. But here’s the rub…
Now use TextEdit to carry out step 2. The tail output will now show that recent edit even before you save your edit to disk.
I just realized that I hadn’t until recently grasped this aspect of the macOS versioning system.
To me this is relevant because I often rely on shell scripts that extract data from some set of log files and then chart that data. I recently had to make a manual modification to one of those log files and inadvertently ran my whole analysis stack before I had saved my minor edits. I then almost tripped when I realized my changes had somehow made it all the way to the final output even before I had saved them. And then it dawned on me that I had just used TextEdit instead of my usual Emacs to make those changes because I was on another system where I didn’t have Emacs readily available.
Anyway, just a reminder how very different things behave if apps use this new versioning model — well, probably, not really that new considering IIRC the revamped macOS versioning system came out with Lion in 2011.
This is a good example of why I have never liked Autosave and Versioning. There used to be a way to disable this but I don’t think it’s possible anymore.
For example, the command the Simon suggested, tail -n10 doc.txt, uses the “tail” command to display the last ten lines of the file “doc.txt”.
The basic structure of a command line is the command, followed by options (usually starting with a dash “-”), and, depending on the command, the file name(s) of the files you wish to manipulate.
tail -n150 doc.txt will display the final 150 lines of the file.
It may seem obscure, but if you work on the command line, it’s a very quick and handy tool to review log files to see if an action has completed without opening the whole file in Word or some other heavyweight program.
There are a bunch of similar, single-purpose tools available on the command line. Most people never need them, but I find them to be very useful. That said, while they are not particularly hard to use once you get the hang of it, I would class them as an advanced technique, especially if your regular user account has “admin” rights.
The point is that this “ask to save when closing” setting only allows you to revert (by manually not saving), but it has no influence over what is being auto saved to disk before you actually choose to save (or not) the doc when closing it.
In my case, that setting has always been on, yet I clearly see TextEdit has saved changes to disk even before I save them. If I close the doc, per my setting, I am asked if I’d like to save changes. If I then choose no, those changes saved to disk get reverted, but that changes nothing about the fact they had already been written to disk before. And I see no way to prevent that from happening, apart from, of course, not using TextEdit.
This is referring to the standard Unix command, tail, which macOS includes.
The tail command displays the end of a text file. By default, it displays the last 10 lines, but you can specify an alternate number.
@Simon’s example command, tail -n10 doc.txt means “display the last 10 lines of the file doc.txt”. He could have left out the “-n10” parameter, because the default (for most installations) is to display 10 lines.
And, in case you’re curious, there is a corresponding head command which displays the start of a text file (by default, the first 10 lines).
These examples don’t show it, but the cool thing is you can have tail stay running (via -f) instead of stopping at the end of the file. So, it can monitor a log, always showing you what’s at the end of it.
Autosaving in some Apple apps has not been a secret (“since Lion in 2011”). I can see where it would trip up people doing technical system stuff, and hopefully you can turn it off if desired.
I’m generally annoyed with Apple and others treating users like kindergartners, but the autosaving of TextEdit is really good for unsophisticated users. I have a neighbor I visit regularly to recover things that they’ve accidentally deleted, like their entire document (!)
I agree that the feature can be really helpful. But as you point out, the way it has been implemented interferes with doing “technical system stuff”. What was entirely new to me is that you can in fact not turn it off. Even if you do what we thought amounted to turning it off, it still writes uncommitted changes to disk (until told to revert) and to my knowledge there is no way to turn that automation off. For now, it appears the only thing we can do about that is be aware and make sure not to use such Apple apps (or any 3rd party apps that use the macOS versioning system). The topic is not chastising Apple for a choice (there’s arguably good reasons for offering the system), it’s rather about creating awareness for what can turn out to be a real issue for certain use cases.
An Apple fangirl since the 80s, I’ve become more and more mystified by many of their design decisions, and increasingly disillusioned by the lack of useful software documentation. The Help system has been a joke for many years.
But here’s the rub…