Time Machine: Spit!!!
in [UK Mac]
|
From: Bruce Horrocks on 23 Nov 2009 22:48 Rowland McDonnell wrote: > Bruce Horrocks <07.013(a)scorecrow.com> wrote: >> ---begin--- >> : >> for T in `find $1 -name "*.tex" -print` >> do >> for E in .log .aux .toc .lot .lof > > Okay, I've read your post - but what exactly does the above line do, > *exactly*? And can you explain the for loop syntax? Yes, I've read > bash docs and no I can't work it out from them, which is why I'm asking > you. The find command finds every file from the directory specified in $1 (which is the value of the first parameter on the command line when the command was invoked) that ends in .tex. The back quotes enclosing the find command cause its output to be put onto the command line, separated by spaces. The "for T" command puts each filename into the variable T in turn, the do...done loop being executed once for each. Handily, the filename in T is a full path filename as well (which means we don't have to worry about which directory we are in provided we make sure that we don't corrupt the path bit). For E in etc. iterates through the list supplied on the rest of the line. The list separator is one or more consecutive white space chars. So this particular do...done loop is done 5 times - firstly with E set to ".log", then with E set to ".aux" and so on. > >> do >> R=`echo $T | sed s/\.tex$/$E/` > > Hmm - and this line, for that matter. It's the sed bit I'm curious > about. At this point T contains the filename of your TeX file, something like: /Users/bruce/test/test.tex "echo $T |" pipes the value of T into sed. (Necessary because - in general terms - sed expects the commands that it executes to be specified on the command line and the data to operate on in an input file.) The s/\.tex$/$E/ tells sed to substitute the value of E for the ".tex" bit of any line that ends ".tex". (The backslash escapes the . in ..tex otherwise it would pattern match any character.) The result is five, full pathnames (one per iteration of the for E loop) /Users/bruce/test/test.log /Users/bruce/test/test.aux /Users/bruce/test/test.toc /Users/bruce/test/test.lot /Users/bruce/test/test.lof Again the use of backquotes means that each of these is put into the variable R which is then deleted by the rm command in the next line. Note that the use of R as an intermediate variable is not necessary but always advisable when deleting files because it is easy to print the value and see exactly what is going to be deleted before using the script in anger. If a full TeX run creates each of these files then all will be deleted with no errors (assuming you have the right file permissions etc.) If the TeX run aborts in the middle for some reason, then some of these might not be created, in which case a "No such file or directory" error is reported. These are harmless and can be ignored. > >> echo rm $R >> done >> done >> ---end--- >> >> Copy all the lines between begin and end into a file called whatever you >> want (let's assume it's "TeXtidy.sh"). >> >> You invoke it from Terminal as >> >> $ . ./TeXtidy.sh start_dir_name >> >> where start_dir_name is the directory you want to start the recursion >> from. (Note that is "dot space dot slash" at the beginning.) > > Hmm - I'd rather be able to invoke it by dropping the directory I want > on to something. Maybe I'll be able to figure something out about that. A small AppleScript (search on "AppleScript droplet") that invokes my script would do this. >> Haven't got time now but will have a look. > > Well, just a fragment of help would do. Okay. Late now. Will have a look into it tomorrow (later today). Regards, -- Bruce Horrocks Surrey England (bruce at scorecrow dot com)
From: T i m on 24 Nov 2009 04:27 On Sat, 21 Nov 2009 22:11:02 +0000, thewildrover(a)me.com (Andy Hewitt) wrote: >One thing to consider as a possibility is the chance of copying a >corrupt file into a backup. With the types that overwrite existing >files, this is a very high possibility, and means you could easily copy >a corrupt file at the time of an imminent system failure. Of course (so you will have lost nothing in that instance) but none of that is what this ClickFree solution is all about (and this isn't particularly to you). ;-) 1) It provides a hands off provision of 'a backup' [1] where one might not otherwise be done at all. If you wanted a history of backups then there is nothing stopping you copying the backup folder onto another drive / computer or simply renaming the folder, forcing a fresh backup next time. All too complicated for a std user though. Also, how big might a backup drive need to be to *guarantee* you weren't carrying a corrupt backup file with a first in first out overwrite system (like TM)? [2] 2) The backup media is (typically) disconnected once the backup is complete so no chance of a power surge destroying computer AND backup hardware / data. [2] 3) Because of it's portability (and the fact that it's *normally disconnected*) it is easier to take > leave off site. [2] 4) It's faster than a complete (system) backup and a system backup would be little use to most std users. 5) It also lends itself to being used as a portable data drive (rather than backup per-se). eg. Mate runs garage. He uses Sage for his accounts and the old Windows 3.1 'Cardfile' for his phone book,vehicle history and a couple of others.[3] He also types the odd document and saves the odd vehicle related picture. As he's about to finish for the night he plugs in his ClickFree drive and it automatically copies all new / modified files to the drive and he puts the drive in his pocket. When he gets home he can 'restore' any / all of his data to his home PC for extra access (He can't use Macs as many of the apps he uses are Windows only, like the Autodata CD's [4]). Simples. ;-) Did you read Elliott's proposed final solution for his backup? Cheers, T i m [1] And we are particularly talking Windows / non TM here, since I found out the Mac use was far too restricted. Plus, it's probably that 'Mac users' are a) actually going to be producing 'data' and b) more likely to understand the risks and already doing something about it. [2] Better to have access to a reasonable backup than no access to a perfect one. They are the only choices for many. [3] I wrote him a little batch file that copies said Cardfile data-files to the daily_pen_drive_backup_system I instigated for him a while back. There is a very good chance he doesn't use it, not because he would like to lose his data but because the effort isn't worth the perceived (and proven to be 'nil' over many years so far) risk. [4] Windows 2000, XP or Vista. Microsoft Internet Explorer 5.5 upwards. http://www.autodata.ltd.uk/technical-specifications.asp
From: Rowland McDonnell on 24 Nov 2009 05:55 Bruce Horrocks <07.013(a)scorecrow.com> wrote: > Rowland McDonnell wrote: > > Bruce Horrocks <07.013(a)scorecrow.com> wrote: > >> ---begin--- > >> : > >> for T in `find $1 -name "*.tex" -print` > >> do > >> for E in .log .aux .toc .lot .lof > > > > Okay, I've read your post - but what exactly does the above line do, > > *exactly*? And can you explain the for loop syntax? Yes, I've read > > bash docs and no I can't work it out from them, which is why I'm asking > > you. > > The find command finds every file from the directory specified in $1 [snip rest of it] Ta muchly. Very useful. My head's not in the right place to fix the information yet. Another reply will follow (sorry) - just wanted to say `thanks'. Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: zoara on 24 Nov 2009 06:01 Peter Ceresole <peter(a)cara.demon.co.uk> wrote: > Bella Jones <me9(a)privacy.net> wrote: > > > > English Breakfast, or Lapsang Souchong? > > > > Oh, always English breakfast! > > I now have Lapsang Souchong tea bags. Since Sainsbury's at Dog Kennel > Hill started to stock them, my breakfasts have been transformed. It's > like drinking a cup of hot bacon. Divine. Presumably these teabags are the type that come attached to a little piece of string, right? -zoara- -- email: nettid1 at fastmail dot fm
From: zoara on 24 Nov 2009 06:01
Andy Hewitt <thewildrover(a)me.com> wrote: > > > On Sat, 21 Nov 2009 17:34:12 +0000, thewildrover(a)me.com (Andy > > Hewitt) > > wrote: > > >> > > >> Well I copied some stuff onto my PC yesterday (just as a stepping > > >> stone) then did some scanning then a backup and noticed it also > > > > backed > > >> up the stuff I put on there temporarily (someone's 'My Docs' I > > > > was > > >> holding for them). I'll stick them on DVD then delete them from > > > > my PC > > >> and do another backup and let you know. ;-) > > > > > Erm, well, it seemed to leave the copies of the files deleted on the > > hdd, on the backup, sorta what I expected to happen (is that right)? > > > > Modifying a test file leaves the last version on the backup. > > Yes, that's a pretty standard backup. Doesn't sound like it. If the disk dies and you restore from backup, how will you know which files were the ones you wanted and which were the ones that you deleted months ago and no longer require? > > Not as sophisticated as TM I know but better than nuffink. ;-) > > Not really, it's 'different'. I think that's the bit that many don't > get > with TM, it is different to most other backup solutions. It's kind of > a > hybrid between an archival backup, and a clone of your current system. Actually, it seems like a very standard backup system to me. There always seems to be some confusion as to what a backup actually is, partly because it's vaguely defined, partly because it's an umbrella term for different types of "backing up", and partly because people misuse or misunderstand it. Someone once wrote a decent article on backup types, but I can't find it now. I'm pretty sure it was the eBook "Take Control of Mac OS X Backups" by Joe Kissell at http://takecontrolbooks.com/backup-macosx The definitions of backup types boiled down to this: Mirror/clone: reflects a single snapshot of a drive or folder at a given point in time; useful only for temporary backup (eg when upgrading disks) or for protecting against hard disk failure. Most implementations create a bootable clone, which proper backups (see below) will not do (at least if any do, I haven't seen them) Archive: Copies of files or folders are created, and then the orginals are deleted from the source. Intention is to free up space on the source by removing infrequently-used files. Does not offer any protection. Backup: stores multiple snapshots of a drive or folder at given points in time. State (ie the data that is there as well as the data that *isn't*) can be restored from any of these snapshots regardless of changes made to the state since the snapshot was taken. Can be a manual collection of mirrors (say seven mirrors rotated through one each day, giving the possibility of going back a week) but is more usually an automated system that stores deltas (differences) between a previous backup and the current state of the disk, so is able to store (say) ten 100GB snapshots in far less than 1TB of space. Time Machine is a classic example of a backup system, with the added cleverness (through the use of hard-linked folders) that snapshots store only the minimum delta required yet can be browsed without any software other than a file browser. Most backups are either easily-browsed but not efficiently stored, or are stored in the minimum space but can't be browsed without using the backup software. What T i m has is almost a mirroring system, but not quite as it doesn't mirror all files (and doesn't produce a bootable disk, which is pretty much the only advantage mirrors have over proper backups). -zoara- -- email: nettid1 at fastmail dot fm |