Just upload the file to something like "my_script.cgi.new". It can
take as long as it needs to transfer. Once it's transferred, rename
>I've done that too, but it's a rather laborious solution to what
must be a rather common task and I'm thinking there could be a more
automated way to deal with it.
[ObDisclosure: I'm the author of Interarchy]
The problems with putting this into Interarchy is that there is no
guarantee that just because you can upload and overwrite a file, you
can safely upload to a different name, delete the file, and then
rename the file to the old name. The server may allow upload
overwriting, but may not allow delete, not allow rename, change the
name transparently on the uploaded file such that the rename fails,
etc, etc. Especially for FTP there are so many ways the servers can
and do misbehave that general solutions to these sorts of problems
require the high level AI in the human brain and are sadly beyond my
(or I would probably go so far as to say anybody's) ability to solve
in a way that would work for all cases.
These is also the specific problem of this upload/delete/rename
solution that the uploaded file will not retain the permissions of
the original, which normally is the case for an upload/overwrite.
Any solution you implement in AppleScript or Perl would need to take
this in to account.
The approach I would tend to take would involve more infrastructure
- setting up version control (say, subversion or cvs over ssh or
tls) and do my save into the [remote] version control system. Then
the task on the other end just involves sync'ing or exporting or
updating with respect to the relatively local system. As others have
noted, this doesn't get rid of the potential for race conditions,
but it does allow you to work and upload your work without the sense
that you're modifying the "live" version of the file out from under
someone.
Yes, this would also be my suggestion (and indeed is what we do for
our web site). BBEdit works on a local copy. Interarchy mirrors the
local copy up to a working copy on the server (and Auto Upload with a
trivial macro can allow the current document in BBEdit to be uploaded
immediately for rapid testing). When all is well with the working
copy on the server (which in our case is live on another port, but
only accessible from our network), then rsync is used on the server
to copy the working copy to the live copy.
As stated, there is always a short period where the user may get
inconsistent results. Short of toggling the live directory (or
machine or IP address), this is always going to be the case when
applying multiple changes. But the time is now reduced to the local
rsync time, which is likely to be nearly instantaneous, and more than
sufficient for any normal site (any site without enough traffic to
need multiple servers, and not critical enough that money or lives
depend on flawless operation).
And as also stated, BBEdit and Interarchy are both highly scriptable
(using AppleScript, or Perl), so a script that takes the location of
the current window in BBEdit, saves the document back to
document.new, deletes and renames the remote file, and then applies
any permission settings as required by the file extension, would be
relatively straight forward. Mac::Glue would make this a Perl script
task.
Enjoy,
Peter.
--
<http://www.stairways.com/> <http://download.stairways.com/>
