Re: LWP::Simple - Terminal won't but BBEdit will.

[Andrew Brosnan]

On 7/9/06 at 6:03 PM, [EMAIL PROTECTED] (Sherm Pendley) wrote:

> On Jul 9, 2006, at 5:03 PM, Andrew Brosnan wrote:
> > 
> > my $file = 'Users/andrewbr/Desktop/google.html';

> Easy fix - add a / to the beginning of $file to make it a fully- 
> qualified path.

Ahh, that was a typo...thanks for proofreading me! :-) I thought I was
loosing it.

Andrew

Re: LWP::Simple - Terminal won't but BBEdit will.

[Sherm Pendley]

On Jul 9, 2006, at 5:03 PM, Andrew Brosnan wrote:


Hi,

I came across something odd editing a script with BBEdit. The  
BBEdit #!

menu has a 'Run' command and a 'Run in Terminal' command. The script
below works fine when I use the Run command, but returns HTTP response
code 500 when I use Run in Terminal. I tried running it directly from
Terminal and I get the same result, HTTP response code 500.

I also noticed that getstore() returns 500 as a one-liner from  
Terminal

(but getprint() works fine). What gives?

Regards,
Andrew


#!/usr/bin/perl

use warnings;

use strict;

use LWP::Simple;

my $url = 'http://www.google.com';

my $file = 'Users/andrewbr/Desktop/google.html';


$file is a relative path. When you use "Run", the current directory  
is '/' (inherited from BBEdit), so the relative path resolves  
correctly to "/Users/andrewbr/Desktop/google.html". When you choose  
"Run in Terminal", or run it manually, the current directory is the  
directory the script lives in, so getstore() tries to store the  
returned data in "(current directory)/Users/andrewbr/Desktop/ 
google.html" - probably not what you had in mind.


getprint() works because it's not trying to write to a non-existent  
directory.


Easy fix - add a / to the beginning of $file to make it a fully- 
qualified path.


sherm--

Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

LWP::Simple - Terminal won't but BBEdit will.

[Andrew Brosnan]

Hi,

I came across something odd editing a script with BBEdit. The BBEdit #!
menu has a 'Run' command and a 'Run in Terminal' command. The script
below works fine when I use the Run command, but returns HTTP response
code 500 when I use Run in Terminal. I tried running it directly from
Terminal and I get the same result, HTTP response code 500.

I also noticed that getstore() returns 500 as a one-liner from Terminal
(but getprint() works fine). What gives?

Regards,
Andrew


#!/usr/bin/perl

use warnings;

use strict;

use LWP::Simple;

my $url = 'http://www.google.com';

my $file = 'Users/andrewbr/Desktop/google.html';

my $res = getstore($url, $file)
or die "Couldn't get/store $url";

print $res;

Re: Delay in BBEdit/TextWrangler

[John Delacour]

At 6:41 am +0900 7/12/05, Joel Rees wrote:

First guess is font caching, which is mostly the time to find and 
load glyphs. It looks like you might be also implicitly invoking the 
relevant parsing attribute tables, which will also take some time to 
find and load.


It's interesting (to me) that if I go for Korean characters rather 
than Burmese, there is no appreciable delay.  It seems some sort of 
obstacle exists in the way of finding the necessary font/glyphs.



#!/usr/bin/perl
binmode STDOUT, q~:utf8~;
###for (4096..4129) {
for (44032..44066) {
  $c = chr();
  $text .= qq~$_\t$c$/~;
}
print $text;

I'll try to narrow it down by testing with various runs of characters.

JD

Re: Delay in BBEdit/TextWrangler

[Joel Rees]

On 2005.12.7, at 04:10 AM, John Delacour wrote:



The script below prints a list of 34 Burmese characters.  I happen to 
have a font for these but I'm not sure that matters.


If I run the script in BBEdit or TextWrangler just after launching the 
apps, there is a huge delay before the output is printed (up to 15 
seconds) but subsequent runs produce no special delay.


First guess is font caching, which is mostly the time to find and load 
glyphs. It looks like you might be also implicitly invoking the 
relevant parsing attribute tables, which will also take some time to 
find and load.



#!/usr/bin/perl
binmode STDOUT, q~:utf8~;
for (4096..4129) {
  $c = chr();
  $text .= qq~$_\t$c$/~;
}
print $text;

I get the same sort of behaviour if I run the script in Script Editor 
or Smile as a shell script, but there is no delay running it in 
Terminal.


Perhaps this reflects that terminal has advanced quite a bit since 
jaguar, to the point of pre-loading many of the relevant tables? 
Perhaps Script Editor and Smile are also loading some sort of run-time 
interpreter which has to do its own caching of font and parsing tables?


Perhaps those two are using Java, maybe? Java does a lot of pre-flight 
checking both syntax and rudimentary semantics for security purposes.


Perhaps they are loading a separate copy of the perl interpreter?


Can anyone explain what causes this delay?


Good question.


JD

Delay in BBEdit/TextWrangler

[John Delacour]

The script below prints a list of 34 Burmese characters.  I happen to 
have a font for these but I'm not sure that matters.


If I run the script in BBEdit or TextWrangler just after launching 
the apps, there is a huge delay before the output is printed (up to 
15 seconds) but subsequent runs produce no special delay.



#!/usr/bin/perl
binmode STDOUT, q~:utf8~;
for (4096..4129) {
  $c = chr();
  $text .= qq~$_\t$c$/~;
}
print $text;

I get the same sort of behaviour if I run the script in Script Editor 
or Smile as a shell script, but there is no delay running it in 
Terminal.


Can anyone explain what causes this delay?

JD

Re: BBEdit/Interarchy

[Peter N Lewis]

At 7:39 +0900 4/6/05, Joel Rees wrote:

On 2005.6.4, at 04:31 AM, Ken Williams wrote:
Actually, it *would* entirely solve the problem.  Renaming a file 
is an atomic operation, there's no point at which anybody could 
get a partial file.  People still reading the old file would be 
fine too, even if the rename happened while they're in the middle 
of reading; the old file is readable until they close it.


Peter pointed out in a private email that this isn't reliable using 
FTP's rename functionality


I'd like a peek at what he wrote, if nobody minds.


Sorry, I was trying to reduce the noise as we drift further and 
further off topic, but it seems ti just added more.


At 23:27 +0800 3/6/05, Peter N Lewis wrote:
We're getting a bit too esoteric to continue on the list, but this 
depends on the FTP server allowing rename/overwrite, which is far 
from guaranteed, even under unix.  There are quite a few FTP servers 
which will give an error in that case, so you would need to delete 
the file first and then rename, destroying the atomicness of the 
operation.


 (if your FTP even supports it) - what I meant in the above, though 
I wasn't clear, was to use /bin/mv on the server, not a rename 
through the FTP connection.


Now, I wouldn't want to stir too much oil into the water, but I'm 
imagining strange things like, ssh would not have such problems 
(assuming you knew that the server was a regular *NIX server and the 
server's file system was a system with proper inodes)?


Yes, presuming you ssh in, and then apply the old permissions to the 
new file and then do a mv (much like the script Bill ended up 
writing), you'd be safe for at least the mainstream unix systems I 
would think.


Enjoy,
   Peter.

--
  

Re: BBEdit/Interarchy

[Joel Rees]

On 2005.6.4, at 04:31 AM, Ken Williams wrote:



On Jun 3, 2005, at 7:34 AM, Ken Williams wrote:



On Jun 2, 2005, at 10:16 AM, Bill Stephenson wrote:
So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload 
is complete with one click. Obviously, this doesn't entirely solve 
the problem, but it does reduce the potential.


Actually, it *would* entirely solve the problem.  Renaming a file is 
an atomic operation, there's no point at which anybody could get a 
partial file.  People still reading the old file would be fine too, 
even if the rename happened while they're in the middle of reading; 
the old file is readable until they close it.


Peter pointed out in a private email that this isn't reliable using 
FTP's rename functionality


I'd like a peek at what he wrote, if nobody minds.

 (if your FTP even supports it) - what I meant in the above, though I 
wasn't clear, was to use /bin/mv on the server, not a rename through 
the FTP connection.


Now, I wouldn't want to stir too much oil into the water, but I'm 
imagining strange things like, ssh would not have such problems 
(assuming you knew that the server was a regular *NIX server and the 
server's file system was a system with proper inodes)?


I consider this on topic, myself, because it's definitely one of the 
things we have to think about when using perl on our Mac OS X boxes. 
(Urging Peter to add ssh functionality to interarchy might not be on 
topic, perhaps.)


--
Joel Rees
Re-inventing the wheel --
One of these days it'll be time to properly implement this wheel thing,
bang off all the corners so it can actually roll.

Re: BBEdit/Interarchy

[Bill Stephenson]

On Jun 2, 2005, at 10:16 AM, Bill Stephenson wrote:
So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload 
is complete with one click. Obviously, this doesn't entirely solve 
the problem, but it does reduce the potential.


Actually, it *would* entirely solve the problem.  Renaming a file is 
an atomic operation, there's no point at which anybody could get a 
partial file.  People still reading the old file would be fine too, 
even if the rename happened while they're in the middle of reading; 
the old file is readable until they close it.


Peter pointed out in a private email that this isn't reliable using 
FTP's rename functionality (if your FTP even supports it) - what I 
meant in the above, though I wasn't clear, was to use /bin/mv on the 
server, not a rename through the FTP connection.


 -Ken




Thank you to everyone for the help.

Peter provided a great explanation about why FTP is not suited for this 
problem. I played with the Applescript "Script Recorder" and didn't get 
too far, there may be a way to use Applescript, I just don't know much 
about it.


Here's what I did come up with to make this easier for me..

Open the file from the remote server with BBEdit.
Use the "Save a Copy to FTP Server" menu command and save the file with 
a new name


Then I wrote this cgi script on the remote server to chmod and rename 
the file...

===
#!/usr/bin/perl

use strict;
use warnings;
use CGI;
use CGI::Carp('fatalsToBrowser');

my $Q = new CGI;

print $Q->header;

print $Q->start_html;

my $mode = 0755;

chmod $mode, 'app.cgi-new' or die ("Error 1: $!");

rename("app.cgi-new","app.cgi") or die("Error 2: $!");

print "All Done";

print $Q->end_html;
===

This isn't as good as I'd like, but it's easier than what I did before.

I know this solution now takes this pretty much way OT and so I 
apologize...


Kindest Regards,

--
Bill Stephenson

Re: BBEdit/Interarchy

[Ken Williams]

On Jun 3, 2005, at 7:34 AM, Ken Williams wrote:



On Jun 2, 2005, at 10:16 AM, Bill Stephenson wrote:
So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload 
is complete with one click. Obviously, this doesn't entirely solve 
the problem, but it does reduce the potential.


Actually, it *would* entirely solve the problem.  Renaming a file is 
an atomic operation, there's no point at which anybody could get a 
partial file.  People still reading the old file would be fine too, 
even if the rename happened while they're in the middle of reading; 
the old file is readable until they close it.


Peter pointed out in a private email that this isn't reliable using 
FTP's rename functionality (if your FTP even supports it) - what I 
meant in the above, though I wasn't clear, was to use /bin/mv on the 
server, not a rename through the FTP connection.


 -Ken

Re: BBEdit/Interarchy

[Steve Axthelm]

At 11:14 on 2005/06/03, [EMAIL PROTECTED] (John Horner) wrote:

> I don't think there's going to be an easy way to over-ride the 
> default "transparent" behaviour of BBEdit/Interarchy to solve your 
> problems. That is, whatever you come up with may not be able to be 
> mapped to the application's "Save" command itself.

BBEdit is attachable - assuming the scripting end could be worked out, 
attaching the script to a menu command won't be a hitch.


-Steve

--
Steve Axthelm
[EMAIL PROTECTED]

Re: BBEdit/Interarchy

[Joel Rees]

So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload 
is complete with one click. Obviously, this doesn't entirely solve 
the problem, but it does reduce the potential.


Actually, it *would* entirely solve the problem.  Renaming a file is 
an atomic operation, there's no point at which anybody could get a 
partial file.  People still reading the old file would be fine too, 
even if the rename happened while they're in the middle of reading; 
the old file is readable until they close it.


This is all on Unix-ish platforms, though.  Windows servers are 
probably all screwed up about it.


inodes are wonderful things.

But now it occurs to me to wonder whether UFS over HFS+ fully emulates 
this behavior.


I've used it in rotating httpd logs, and it seems to work.

--
Joel Rees
Re-inventing the wheel --
One of these days it'll be time to properly implement this wheel thing,
bang off all the corners so it can actually roll.

Re: BBEdit/Interarchy

[Ken Williams]

On Jun 2, 2005, at 10:16 AM, Bill Stephenson wrote:
So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload 
is complete with one click. Obviously, this doesn't entirely solve the 
problem, but it does reduce the potential.


Actually, it *would* entirely solve the problem.  Renaming a file is an 
atomic operation, there's no point at which anybody could get a partial 
file.  People still reading the old file would be fine too, even if the 
rename happened while they're in the middle of reading; the old file is 
readable until they close it.


This is all on Unix-ish platforms, though.  Windows servers are 
probably all screwed up about it.


 -Ken

Re: BBEdit/Interarchy

[Peter N Lewis]

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/>

Re: BBEdit/Interarchy

[Charles Albrecht]

At 10:16 AM -0500 6/2/05, Bill Stephenson wrote:
>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.

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.

-Charles
 [EMAIL PROTECTED]

Re: BBEdit/Interarchy

[Jay Savage]

On 6/2/05, Sherm Pendley <[EMAIL PROTECTED]> wrote:
> On Jun 2, 2005, at 7:33 PM, Joel Rees wrote:
> 
> > Race conditions don't go away just because you have high speed
> > connections.
> 
> Quite true, but high speed connections *do* shrink the time window,
> considerably reducing the risk. Unless you have an application that
> absolutely, positively, must *never* fail, you can easily get to a
> point where the risk is too low to justify the effort of lowering it
> even further.
> 
> sherm--

Exactly.

Race conditions don't go away even if you take the the network out of
the connection entirely.  There's still a very small even with the mv
option.  But the faster the copy can happen, the less chance of a
request being issued while it's unsable.  If it takes an hour to write
a file, there's a pretty good change many people are going to get
505's or 404's.  If it takes 1/10th of a second to shuffle some
pointers, theres a pretty good chance no one will ever know.

And "unusable" is really what we're talking about here, not race
conditions.  I don't think there's much potential for a true race
condition.  First, hopefully the OS is sane, and second, there's one
reading process and one writing process.  That's not problematic from
a scheduling standpoint, unless I was absent the day tail got defined
as a race condition; it's not exactly fertile ground for an infinte
loop.  The problem is that the OP would like for the web server to
have access to a complete (old) file until the complete new file is
available.

And there are two solutions to that I can see: 1) get a connection
fast enough to narrow the window of opportunity to within the bounds
of acceptability, or 2) bait and switch.

-- jay

daggerquill [at] gmail [dot] com
http://www.engatiki.org

Re: BBEdit/Interarchy

[John Horner]

I don't think there's going to be an easy way to over-ride the 
default "transparent" behaviour of BBEdit/Interarchy to solve your 
problems. That is, whatever you come up with may not be able to be 
mapped to the application's "Save" command itself.


But what you want to do is essentially trivial, when looked at as an 
Applescript problem:


"Can I create a command, which can be called when editing a file
in BBEdit, saves the file to an FTP server, with a given prefix
or suffix on the filename, then renames two files on that server?"

the answer is definitely yes and should be short work for AppleScript 
/ BBEdit / Interarchy gurus. You're just asking on the wrong list, 
that's all.

Re: BBEdit/Interarchy

[Sherm Pendley]

On Jun 2, 2005, at 7:33 PM, Joel Rees wrote:

Race conditions don't go away just because you have high speed  
connections.


Quite true, but high speed connections *do* shrink the time window,  
considerably reducing the risk. Unless you have an application that  
absolutely, positively, must *never* fail, you can easily get to a  
point where the risk is too low to justify the effort of lowering it  
even further.


sherm--

Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Re: BBEdit/Interarchy

[Joel Rees]

I think I'm going to be disagreeable ...

On 2005.6.3, at 05:23 AM, Jay Savage wrote:


On 6/2/05, Bill Stephenson <[EMAIL PROTECTED]> wrote:

On Jun 1, 2005, at 4:40 PM, Jay Savage wrote:


Bill,

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
it.

HTH,

-- jay

daggerquill [at] gmail [dot] com
http://www.engatiki.org




Thanks for the reply Jay,

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. Since both BBEdit and Interarchy are
already built to work together I was hoping that someone more familiar
with their guts may have worked on it already.

So I guess what I'm asking is if there a way to get either of these
apps to upload a file with a new name and rename it after the upload 
is

complete with one click. Obviously, this doesn't entirely solve the
problem, but it does reduce the potential.

Kindest Regards,



The answer is probably no.  At least not out of the box.  It's not
really all that common, at least not any more: most "mission critical"
apps are maintained on reasonably high speed connections.


Race conditions don't go away just because you have high speed 
connections.



 In most
cases if you're working on an application where a customer just
absolutely can't get a 505 error, ever. The comapany pays for a cable
or T1--or at least DSL--connection. And usually, if it's that
important, especially if you're using renaming to aviod connection
problems, you don't want the process to be automated.  You want to do
it by hand to make sure it works, and you want to verify the checksums
on both the download and the upload, just to be sure you've got
everything.  So no, this probably isn't as common as it seems,
although it was certainly more common 5 years ago.

That said, interarchy is extremely AppleScriptable.


Bingo.

In fact, I'll bet you can get into Interarchy through perl, but then 
you can also go direct to ftp or ssh through perl, as well. Set up an 
entire separate directory hierarchy, shut down the sessions more or 
less gracefully, and mv the root of the new one over the top of the old 
one before bringing the server back up.


And the really big sites actually load the new site on a separate (set 
of) server(s) and switch the IP addresses all at once.



 You should be
able to whip up something fairly quickly.  If you poke around the
Interarchy users group (it's linked from the website) there may even
be something out there already.

Anothe option would be to set up a cron job on the server to
periodically rename files with a certain extension.

HTH,

-- jay 


daggerquill [at] gmail [dot] com
http://www.engatiki.org

Re: BBEdit/Interarchy

[Jay Savage]

On 6/2/05, Bill Stephenson <[EMAIL PROTECTED]> wrote:
> On Jun 1, 2005, at 4:40 PM, Jay Savage wrote:
> 
> > Bill,
> >
> > 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
> > it.
> >
> > HTH,
> >
> > -- jay
> > 
> > daggerquill [at] gmail [dot] com
> > http://www.engatiki.org
> >
> >
> 
> Thanks for the reply Jay,
> 
> 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. Since both BBEdit and Interarchy are
> already built to work together I was hoping that someone more familiar
> with their guts may have worked on it already.
> 
> So I guess what I'm asking is if there a way to get either of these
> apps to upload a file with a new name and rename it after the upload is
> complete with one click. Obviously, this doesn't entirely solve the
> problem, but it does reduce the potential.
> 
> Kindest Regards,
> 

The answer is probably no.  At least not out of the box.  It's not
really all that common, at least not any more: most "mission critical"
apps are maintained on reasonably high speed connections.  In most
cases if you're working on an application where a customer just
absolutely can't get a 505 error, ever. The comapany pays for a cable
or T1--or at least DSL--connection. And usually, if it's that
important, especially if you're using renaming to aviod connection
problems, you don't want the process to be automated.  You want to do
it by hand to make sure it works, and you want to verify the checksums
on both the download and the upload, just to be sure you've got
everything.  So no, this probably isn't as common as it seems,
although it was certainly more common 5 years ago.

That said, interarchy is extremely AppleScriptable.  You should be
able to whip up something fairly quickly.  If you poke around the
Interarchy users group (it's linked from the website) there may even
be something out there already.

Anothe option would be to set up a cron job on the server to
periodically rename files with a certain extension.

HTH,

-- jay 

daggerquill [at] gmail [dot] com
http://www.engatiki.org

Re: BBEdit/Interarchy

[Bill Stephenson]

On Jun 1, 2005, at 4:40 PM, Jay Savage wrote:


Bill,

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
it.

HTH,

-- jay

daggerquill [at] gmail [dot] com
http://www.engatiki.org




Thanks for the reply Jay,

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. Since both BBEdit and Interarchy are 
already built to work together I was hoping that someone more familiar 
with their guts may have worked on it already.


So I guess what I'm asking is if there a way to get either of these 
apps to upload a file with a new name and rename it after the upload is 
complete with one click. Obviously, this doesn't entirely solve the 
problem, but it does reduce the potential.


Kindest Regards,

--
Bill Stephenson

Re: BBEdit/Interarchy

[Jay Savage]

On 6/1/05, Bill Stephenson <[EMAIL PROTECTED]> wrote:
> I use Interarchy to download perl scripts I want to edit with BBedit.
> BBEdit uses Interarchy to save the scripts.
> 
> When I save a the perl script I first have to check to see if there is
> a recently active user so the user doesn't get an error while trying to
> access the script again while I'm in the middle of uploading it with my
> really slow dial-up connection.
> 
> This really doesn't work very well and I need a better way to handle
> this.
> 
> Anyone have a solution/suggestion?
> 
> Kindest Regards,
> 
> --
> Bill Stephenson
> 
> 

Bill,

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
it.

HTH,

-- jay

daggerquill [at] gmail [dot] com
http://www.engatiki.org

Re: BBEdit/Interarchy

[Troy Davis]

Hi Bill,

Two options that are pretty simple:

1. Save the script with a different name until you've got the changes  
working, then swap the files.


2. Setup a test site on the same server with a separate domain name  
like test.yourclient.com. Then you can experiment to your heart's  
content on the entire infrastructure without interrupting public  
access to the production site.


HTH,
Troy
__
Troy Davis
Technology Director
Metaphor Studio
538 Reading Road
Loft 200
Cincinnati, Ohio 45202

Tel: 513-723-0290
Fax: 513-723-0670
http://metaphorstudio.com

On Jun 1, 2005, at 3:30 PM, Bill Stephenson wrote:

I use Interarchy to download perl scripts I want to edit with  
BBedit. BBEdit uses Interarchy to save the scripts.


When I save a the perl script I first have to check to see if there  
is a recently active user so the user doesn't get an error while  
trying to access the script again while I'm in the middle of  
uploading it with my really slow dial-up connection.


This really doesn't work very well and I need a better way to  
handle this.


Anyone have a solution/suggestion?

Kindest Regards,

--
Bill Stephenson

BBEdit/Interarchy

[Bill Stephenson]

I use Interarchy to download perl scripts I want to edit with BBedit. 
BBEdit uses Interarchy to save the scripts.


When I save a the perl script I first have to check to see if there is 
a recently active user so the user doesn't get an error while trying to 
access the script again while I'm in the middle of uploading it with my 
really slow dial-up connection.


This really doesn't work very well and I need a better way to handle 
this.


Anyone have a solution/suggestion?

Kindest Regards,

--
Bill Stephenson

remote BBEdit script

[Ray Zimmerman]

On Mar 2, 2005, at 8:31 PM, Peter N Lewis wrote:
This has been mentioned a few times, but of course TextWrangler/BBEdit 
both support Edit via FTP/SFTP, so presuming you are SSHing to your 
target machine, then you can easily edit remote files with 
TextWrangler/BBEdit.

For example, on the target machine while logged in via ssh, you can do 
this:

ssh [EMAIL PROTECTED] bbedit 
sftp://[EMAIL PROTECTED]/perl/Peter/Tools.pm

I'll leave as an exercise to the perl hacker as to how to have to set 
up[ an alias and script to do this by typing

rbbedit Tools.pm
OK, here are the results of my exercise, based mostly on code sent 
directly from Peter (thanks), with a few minor modifications. Save as 
rbbedit somewhere in your $PATH on a remote Unix box, ssh into the box 
from your Mac and type:

rbbedit 
to open the file via SFTP in BBEdit on your Mac. Or
rbbedit 
to open an SFTP directory browser on you Mac. It even works with pipes, 
like:

ls -al | rbbedit
Note: you must have ssh access to your Mac from the Unix box for it to 
work. With the appropriate KeyChain entries and/or 
~/.ssh/authorized_keys I was even able to get it to work without 
prompting me for passwords.

Enjoy ... and many thanks to Peter for the idea and much of the code ...
Ray
P.S. Too bad the bbdiff command-line tool doesn't handle remote files 
...

---
#!/usr/bin/perl -w
use strict;
use File::Spec;
my $default_bb_host = 'mymac.somedomain.org';
my $user = $ENV{USER};
my $host = $ENV{HOSTNAME} || $ENV{HOST};
my $ssh_client = $ENV{SSH_CLIENT} || $ENV{SSH2_CLIENT};
($ssh_client) = $ssh_client =~ /(\d+\.\d+\.\d+\.\d+)/;
my $bb_host = $ENV{REMOTEHOST} || $ssh_client || $default_bb_host;
open_in_bbedit(@ARGV);
sub open_in_bbedit {
my @urls;
while (my $file = shift @_) {
$file = File::Spec->rel2abs( $file );
die "Path with colon! $file"if $file =~ /:/;
die "Does not exist: $file\n"   unless -r $file;
if (-d $file) {
$file .= '/';
} else {
warn "File is read only\n"  unless -w $file;
}
push @urls, "sftp://[EMAIL PROTECTED]/$file";
}
my @cmd = (
'ssh',
$bb_host,
'bbedit',
@urls,
);
print "@cmd\n";
system( @cmd );
}
1;

Re: HTML::Tidy Filter for BBEdit?

[_brian_d_foy]

In article <[EMAIL PROTECTED]>, Paul McCann
<[EMAIL PROTECTED]> wrote:

> Do the items in the "Markup->Tidy" submenu do what you're seeking? I'm
> pretty sure they hook into a copy of HTML Tidy that's embedded in BBEdit.

There is an HTML Tidy in BBEdit, but it only works on the whole
document.  The filter posted earlier works with the current 
selection, which I think was the point of the question. :)

-- 
brian d foy, [EMAIL PROTECTED]

Re: HTML::Tidy Filter for BBEdit?

[John Horner]

I think HTML::Tidy doesn't offer what you're seeking: looks like it's a
validation tool, not a "pretty-print" tool. So your output is empty 
if things are well in the world of your html, and warnings/errors if 
there are problems validating the string HTML::Tidy is fed.
Well, yes and no. Perhaps it seems that way because you're seeing the 
HTML::Tidy documentation offering only to do those things.

But having installed the tidy library on my Mac, I can type
tidy test.html
at the command line and have it give warnings and also print to 
STDOUT a fixed version of my file, e.g. it might say 'Missing 
attribute on line 6', and then it will print out a new version of the 
file with that attribute added.

The option -i will do indenting, i.e. rudimentary formatting, and the 
-m option will edit the file in place rather than dump the corrected 
version out.

So I still remain baffled by the module. Does its "clean" function 
transform a string in place? It doesn't seem to. Where are the 
options? Is it perhaps confused about where tidy is on my system 
(/opt/local/bin/tidy) ?

   "Have You Validated Your Code?"
John Horner(+612 / 02) 9333 3488
Senior Developer, ABC Online  http://www.abc.net.au/

Re: HTML::Tidy Filter for BBEdit?

[Paul McCann]

Hi John,
you wrote...

> my question is, how can I create the same sort of script which will 
> use HTML::Tidy?
> 
> Both the module and the library are installed and running OK on my 
> Mac, but I can't seem to get it to work, in fact I can't even figure 
> out from the documentation how to get any output from it at all!

I think HTML::Tidy doesn't offer what you're seeking: looks like it's a
validation tool, not a "pretty-print" tool. So your output is empty if things
are well in the world of your html, and warnings/errors if there are problems
validating the string HTML::Tidy is fed. 

The following works as a filter in BBEdit, but (as above) I don't think
it'll do what you're seeking!

Do the items in the "Markup->Tidy" submenu do what you're seeking? I'm
pretty sure they hook into a copy of HTML Tidy that's embedded in BBEdit.

Cheers,
Paul
--
#!/usr/local/bin/perl -w
use strict;
use HTML::Tidy;
local $/;
my $input=<>;
my $dummyfilename='input'; 
my $tidy = new HTML::Tidy;
$tidy->parse($dummyfilename, $input );
for my $message ( $tidy->messages ) {
 print $message->as_string;
}
--

HTML::Tidy Filter for BBEdit?

[John Horner]

I have a very useful Perl::Tidy Filter in BBEdit, though I'm not 
quite sure where I got it from.

Essentially it takes input from the selection of the current window, 
and when invoked, writes Tidy'd code back to the selection.

It's terribly simple, in fact I'll post the entire thing here (minus 
a couple of comments):

#!/usr/bin/perl -wn
use Perl::Tidy;
BEGIN { my $input_string = ""; my $output_string = ""; }
$input_string .= $_;
END {
Perl::Tidy::perltidy(
source  => \$input_string,
destination => \$output_string,
);
print "$output_string\n";
}
__END__
my question is, how can I create the same sort of script which will 
use HTML::Tidy?

Both the module and the library are installed and running OK on my 
Mac, but I can't seem to get it to work, in fact I can't even figure 
out from the documentation how to get any output from it at all!

According to 
http://search.cpan.org/~petdance/HTML-Tidy-1.04/lib/HTML/Tidy.pm the 
module only has six methods, none of which returns my HTML to me in 
any form -- am I missing something? The messages say things like 
"deleting empty  tag", but if it doesn't return anything, so what? 
Should I be using the API for libtidy itself, and if so, how?


   "Have You Validated Your Code?"
John Horner(+612 / 02) 9333 3488
Senior Developer, ABC Online  http://www.abc.net.au/

Re: BBEdit as HTML validator back end?

[John Horner]

On 13/11/2004, at 5:48 AM, Sherm Pendley wrote:
If BBEdit can be driven via AppleScript, you should also be able to 
use Mac::Glue to drive it. Or, you could run your AppleScript with the 
"osascript" tool.
That got me on the right track -- to the extent that this is already 
working:

#!/usr/bin/perl
use strict;
use Mac::AppleScript::Glue;
use LWP::Simple;
print "Enter URL:\n -> ";
my $URL =  || die "$!";
getstore( $URL, "/path/to/tempfile.html" ) || die;
my $BB = new Mac::AppleScript::Glue::Application('BBEdit')
  || die "$!";
my $results =
  $BB->check_syntax(
file => "path:to:tempfile.html" )
  || die "$!";
foreach my $item ( @{$results} ) {
print 'Line '
  . $item->{'result_line'} . ': '
  . $item->{'message'} . "\n";
}
I don't quite understand the results data that's coming back from the 
Glue object, but the basics are already there. Of course if it was 
going to be a CGI script there's a lot of other stuff to do but the 
concept is proven at least.

Re: BBEdit as HTML validator back end?

[Sherm Pendley]

On Nov 12, 2004, at 5:24 AM, John Horner wrote:
I can, for instance, easily create an AppleScript which tells BBEdit 
to validate a certain file and write the results to another file -- 
how hard would it be to hook in to that with a CGI script?
If BBEdit can be driven via AppleScript, you should also be able to use 
Mac::Glue to drive it. Or, you could run your AppleScript with the 
"osascript" tool.

sherm--

Installing W3C validator (was Re: BBEdit as HTML validator back end?)

[David Dierauer]

You might also want to look at this article:
http://developer.apple.com/internet/opensource/validator.html

Between it and the mediaville.net article (and W3C's own installation
instructions at http://validator.w3.org/docs/install.html ), I was able to
get the W3C validator working on my mac (OS X 10.3.5) just yesterday.  I
had to install Fink to get OpenSP working; my attempts to build it from
source failed, but other than that, it wasn't too tricky.

I, too, considered how to work BBEdit into the mix, but gave up on it
without doing too much digging into its AppleScript dictionary. I find
AppleScript very frustrating to deal with. But if you have the AppleScript
to get BBEdit to write its validation results to a file, it sounds like
you've got the hard part taken care of, and could easily have the cgi read
in the file and display it.

BTW, I'd be interested in seeing your AppleScript, if you'd be willing to
email it to me, preferably off-list, since it's not really on topic for
this list.

-- 
David Dierauer
[EMAIL PROTECTED]

On Fri, 12 Nov 2004, John Horner wrote:

> I'm working through the instructions on the mediaville.net site, but
> it's going to take a while from the looks of things.
>
> How about my original question, just for the sake of it?
>
> I can, for instance, easily create an AppleScript which tells BBEdit to
> validate a certain file and write the results to another file -- how
> hard would it be to hook in to that with a CGI script?
>
>
> > On Nov 11, 2004, at 7:06 PM, John Horner wrote:
> >
> >> I would like to be able to install a browser-based HTML validator on
> >> my OSX web server
>
>

Re: BBEdit as HTML validator back end?

[John Horner]

I'm working through the instructions on the mediaville.net site, but 
it's going to take a while from the looks of things.

How about my original question, just for the sake of it?
I can, for instance, easily create an AppleScript which tells BBEdit to 
validate a certain file and write the results to another file -- how 
hard would it be to hook in to that with a CGI script?


On Nov 11, 2004, at 7:06 PM, John Horner wrote:
I would like to be able to install a browser-based HTML validator on 
my OSX web server

Re: BBEdit as HTML validator back end?

[John Horner]

 http://validator.w3.org/source/
Instructions for that one are only a couple clicks away:

Thank you. I had no idea. Checking it out now.
It's possible to install these tools on LINUX using PPM
I think you're confused - Linux is not an ancronym, and PPM is for 
Windows. :-)
Yes, indeed, sorry. Hangover. Please substitute "Linux" and "RPM".

Re: BBEdit as HTML validator back end?

[Sherm Pendley]

On Nov 11, 2004, at 7:06 PM, John Horner wrote:
I would like to be able to install a browser-based HTML validator on 
my OSX web server, like the W3C:

 http://validator.w3.org/source/
Instructions for that one are only a couple clicks away:

It's possible to install these tools on LINUX using PPM
I think you're confused - Linux is not an ancronym, and PPM is for 
Windows. :-)

sherm--

BBEdit as HTML validator back end?

[John Horner]

I would like to be able to install a browser-based HTML validator on 
my OSX web server, like the W3C:

 http://validator.w3.org/source/
or WDG:
 http://www.htmlhelp.com/tools/validator/source.html
validators.
It's possible to install these tools on LINUX using PPM but being 
able to hack them and the associated C libraries to work on OSX is 
way beyond my capabilities.

But then it occurred to me I already have an application which does 
HTML validation which works on OSX - BBEdit. Is it a crazy idea that 
it might be possible to pipe a file or string to BBEdit's "Check 
Syntax" command and retrieve the output? Where would I start with 
something like that?

Re: BBEdit 8.0

[Peter J . Hartmann]

I cannot get autocompletion to work with jEdit 4.2 on Panther. Do you 
have
that issue as well?
Works here... (10.3.5 and 4.2 final)


Bild 1.pdf
Description: Adobe PDF document
I guess you have checked edit mode = perl in Buffer Options/Global 
Options?

___ Peter Hartmann 
mailto:[EMAIL PROTECTED]

Re: BBEdit 8.0

[Robert]

I cannot get autocompletion to work with jEdit 4.2 on Panther. Do you have
that issue as well?

Robert

"Pete Prodoehl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Ray Zimmerman wrote:
> > On Sep 9, 2004, at 8:41 PM, Ian Ragsdale wrote:
>
> >> Effortless & transparent handling & switching of line endings.
> >> Powerful HTML tools
> >> Shell "worksheets" (allows easy editing & running of shell commands)
> >> Multi-file regular expression find & replace functionality, with
> >> nameable saveable expressions
> >> Transparent FTP/SFTP support
> >> Easy scriptability and integration with command line tools
> >
> >
> > And don't forget ...
> > multi-file diff, with side-by-side highlighting (integrated with
> > CVS, too).
> > en-tabbing, de-tabbing
> > re-wrapping text
> > inserting, removing line prefixes/suffixes
> > ... to name just a few more. I'm sure many/most of these things are
> > easily doable by someone who's mastered vi or emacs, but it's the
> > learning curve that's kept me from ever doing that.
>
> Of course if you are looking for an editor that covers most/all of these
> and more, and runs on other platforms, and happens to be open-source,
> you might want to check out jEdit - http://jedit.org/ - There are at
> least a few jEdit users who are old-BBEdit users, and there's even a
> page on switching from BBEdit to jEdit (that could use some updating!)
>
>http://community.jedit.org/cgi-bin/TWiki/view/Main/SwitchingFromBBEdit
>
> Pete
>
>
>

Re: BBEdit 8.0 vs JEdit

[Sherm Pendley]

On Sep 12, 2004, at 1:32 PM, The Ghost wrote:
Other than JEdit, my other choice would be KDE's KATE (K Advance Text 
Editor).  (This may now be Quantra, I don't know).  Excellent syntax 
highlighting control, integrated command line, a nice file browser 
(good for looking at logs quickly),  The only problem is I don't know 
how to put it on a Mac, but I'm sure it can be done.  If anyone knows 
how to do this or can point me to the right documentation it'd be much 
appreciated.
KATE is available through Fink. I'm not certain what specific package, 
although kdeutils3 or kdevelop seems likely.

sherm--

Re: BBEdit 8.0 vs JEdit

[Pete Prodoehl]

The Ghost wrote:
I'd really like to reiterate the suggestion to try JEdit.  It used to 
have some problems on OS X, but in 4.2 Final they are cleared up.  It 
has everything with the SFTP, multi-file search/replace with regex 
(better than BBEdit's in IMO), and all that fancy stuff, the only thing 
it doesn't currently have to my knowledge is the ability to execute a 
script from the program.  However, with it's plugin architecture I 
believe this will come in the future.

Ryan
As long as someone brought up jEdit, I'll toss in my 2 cents...
You can execute scripts from jEdit, there are a number of ways, using 
the console plugin, a commando file, a macro, etc... Perhaps the problem 
is that there are multiple ways of doing things, so there's not the "one 
true way" to do something, but asking on the mailing list usually gets 
you some good answers.

A few other nice things about jEdit are: active development, good 
support, open-source, multi-platform... and if you like to customize, 
extend, and hack the heck out of your editor, it's ready, willing, and 
able...

Pete

BBEdit 8.0 vs JEdit

[The Ghost]

I'd really like to reiterate the suggestion to try JEdit.  It used to 
have some problems on OS X, but in 4.2 Final they are cleared up.  It 
has everything with the SFTP, multi-file search/replace with regex 
(better than BBEdit's in IMO), and all that fancy stuff, the only thing 
it doesn't currently have to my knowledge is the ability to execute a 
script from the program.  However, with it's plugin architecture I 
believe this will come in the future.

Other than JEdit, my other choice would be KDE's KATE (K Advance Text 
Editor).  (This may now be Quantra, I don't know).  Excellent syntax 
highlighting control, integrated command line, a nice file browser 
(good for looking at logs quickly),  The only problem is I don't know 
how to put it on a Mac, but I'm sure it can be done.  If anyone knows 
how to do this or can point me to the right documentation it'd be much 
appreciated.

That's my 2 cents.
Ryan

Re: BBEdit 8.0

[Chris Carline]

On Fri, 10 Sep 2004 12:13:43 -0700, Steve Axthelm <[EMAIL PROTECTED]> wrote:
> UltraEdit does a fine job:
> 
> <http://www.ultraedit.com/>

It does, but I prefer TextPad (<http://www.textpad.com>), if only for
the fact that it's the only text editor I've ever seen that handles
line wrapping in The Way It Should Be Done By Everybody. :-)

I believe it's also slightly cheaper than UltraEdit (both TextPad and
UltraEdit are $15-$20 cheaper than the BBEdit 8.0 *upgrade* price, and
are every bit as good - market forces maybe, but if you have a Windows
license knocking around it's *cheaper* to buy VPC and one of these
puppies than it is to buy BBEdit on its own -- *plus* you get the
capabilities to run x86-based operating systems).

Thanks for everyone's comments, by the way. Text editors are the new
religion, honestly ;-)

Re: BBEdit 8.0

[John Siracusa]

On Fri, 10 Sep 2004 12:13:43 -0700, Steve Axthelm <[EMAIL PROTECTED]> wrote:
> >Is there a text editor (preferably something
> >simple) on Windows that allows you to deal with line breaks the way
> >BBEdit does?
> 
> UltraEdit does a fine job:
> 
> <http://www.ultraedit.com/>

...where "fine" is defined as "allows you to accidentally create
documents with many different kinds of line endings" and "has a
jump-to-function feature for perl scripts that is so buggy that it's
nearly useless."   I was not impressed when I used it.  It's not even
in the same galaxy as BBEdit.

-John

Re: BBEdit 8.0

[Joseph Alotta]

Hi Ken,
I have been using emacs in one window and a terminal in another window 
to run the command line.  I tried what you say and the control-z works 
to suspend emacs, but I can't seem to get the .login to work to pop me 
back into emacs.  Does .login work when you start a new terminal 
window, or do I need to logout of my user id?

Joe.
On Sep 9, 2004, at 10:34 PM, Ken Williams wrote:
text, and when I want to run commands I hit control-z and run a perl 
one-liner, or a 'wc' command, or whatever.  Then, since I have 
"bindkey ^Z run-fg-editor" in my .login file, I just hit control-z 
again to drop me back into my editor.  I almost never use emacs' shell 
integration, or write lisp functions, because I find the parent shell 
a more powerful tool.  And this way I g

Re: BBEdit 8.0

[Steve Axthelm]

>Is there a text editor (preferably something
>simple) on Windows that allows you to deal with line breaks the way 
>BBEdit does?

UltraEdit does a fine job:

<http://www.ultraedit.com/>


-Steve

-- 
#! /usr/bin/perl -w
my @wish = qw/60 47 98 117 115 104 62/;
foreach (@wish) {
print chr($_);
};

Re: BBEdit 8.0

[Chris Devers]

Seeing as this has devolved into an editor love-fest, rather than curse 
the darkness and that weird gas odor, I'll light a candle & brighten 
things a bit more. (Or mangle metaphors, or something. I'll stop now.)

I've been putting a copy of SubEthaEdit on all the Macs at work for a 
while now, but none of them seemed to use it until recently -- they were 
all just using BBEdit. But then someone noticed the networking abilities 
in SEE, and they've quickly started using it for collaborating on 
documents, interacting with people elsewhere in the office or over the 
internet, or even as a weird, hyperactive chat framework.

I don't know of any other editor, on any platform, that can do the 
clever networking tricks that SubEthaEdit provides. You can have an 
arbitrary number of users simultaneously making multiple edits to a 
document with an indepentend insertion point into that document for each 
user, and everything happens live as everyone types. This can obviously 
get pretty chaotic, but as long as people follow a little bit of decorum 
(don't carelessly mess with each other's edits) then it isn't too bad.

In theory it should be possible to get other editors hooked into the 
protocol that SEE uses, so that "real" editors like Vim, Emacs, and 
BBEdit can participate, but for now and for the foreseeable future, this 
capability is only available in SEE. That alone makes it worth using.

Aside from that, it's a solid but mostly standard editor. It does things 
like automatic syntax highlighting and preservation of indent level 
(i.e. it will carry over from the previous line, but doesn't seem to 
have magic for increasing or decreasing at block boundaries); it can 
provide a web formatted version of HTML code; it provides regex search & 
replace capabilities; and it has some kind of support for managing 
changes to a document, though I haven't played with this feature.

Learn more here: <http://www.codingmonkeys.de/subethaedit/>
--
Chris Devers

Re: BBEdit 8.0

[Pete Prodoehl]

Ray Zimmerman wrote:
On Sep 9, 2004, at 8:41 PM, Ian Ragsdale wrote:

Effortless & transparent handling & switching of line endings.
Powerful HTML tools
Shell "worksheets" (allows easy editing & running of shell commands)
Multi-file regular expression find & replace functionality, with 
nameable saveable expressions
Transparent FTP/SFTP support
Easy scriptability and integration with command line tools

And don't forget ...
multi-file diff, with side-by-side highlighting (integrated with 
CVS, too).
en-tabbing, de-tabbing
re-wrapping text
inserting, removing line prefixes/suffixes
... to name just a few more. I'm sure many/most of these things are 
easily doable by someone who's mastered vi or emacs, but it's the 
learning curve that's kept me from ever doing that.
Of course if you are looking for an editor that covers most/all of these 
and more, and runs on other platforms, and happens to be open-source, 
you might want to check out jEdit - http://jedit.org/ - There are at 
least a few jEdit users who are old-BBEdit users, and there's even a 
page on switching from BBEdit to jEdit (that could use some updating!)

  http://community.jedit.org/cgi-bin/TWiki/view/Main/SwitchingFromBBEdit
Pete

Re: BBEdit 8.0

[Charlie Garrison]

Good evening,

On 9/9/04 at 3:06 PM -0400, Sherm Pendley <[EMAIL PROTECTED]> wrote:

>Safari and reload the page. I can configure Console.app to 
>automagically pop itself to the front of the window stack whenever 
>anything gets appended to Apache's (or some other) error log.

Then you may also be interested in Tailer+. It simply tails a log file (can do
so with ssh too) but it also highlights and strips lines based on criteria
such as a regex. I find it great for getting to just the data I want to see in
apache error logs.

After Affrus and BBEdit, it's one of the most useful tools in my arsenal.

Charlie

-- 
   Charlie Garrison  <[EMAIL PROTECTED]>
   PO Box 141, Windsor, NSW 2756, Australia

Re: BBEdit 8.0

[Rick Anderson]

On Sep 9, 2004, at 5:41 PM, Ian Ragsdale wrote:
Effortless & transparent handling & switching of line endings.
It's the little things that matter, isn't it? You'd almost be able to 
write-off this feature as trivial until you start dealing with the 
hassles that line endings from different platforms can cause. 
Developing in a mixed platform environment can be a real nightmare.

I do all my Perl scripting in BBEdit on OS X, almost exclusively, 
primarily to avoid issues with line endings. My boss works on a Windows 
machine and occasionally has to alter my scripts there (or data files 
associated with them) forgetting sometimes that Notepad will change the 
line breaks to DOS style which causes the script to fail online. He 
occasionally comments that he wishes there were something on Windows 
like BBEdit.

I've done a lot of searching and a lot of asking around, but have yet 
to find such a thing. Is there a text editor (preferably something 
simple) on Windows that allows you to deal with line breaks the way 
BBEdit does?

--Rick Anderson
"The only difference between me and a madman,
is that I am not mad." -- Salvador Dali

Re: BBEdit 8.0

[Andy Holyer]

On 10 Sep 2004, at 09:59, Andy Holyer wrote:
On 10 Sep 2004, at 02:54, Doug McNutt wrote:
At 19:41 -0500 9/9/04, Ian Ragsdale wrote:
Shell "worksheets" (allows easy editing & running of shell commands)
And there is by far the most important item. When the MacPerl port 
ran as an MPW tool it looked a whole lot like UNIX perl and you could 
run it from a command line, with arguments, and redirect output to 
another open window or to a file. Any open window, if it contained 
"shell" commands, could be invoked as a tool by simply naming it.

I am told, by my son, that the best replacement for MPW in OS neXt is 
really emacs but it requires that I learn smalltalk or something 
similar and, though I have read the book, I just ain't there. X11 
isn't that easy to use either with my four monitors.

Lisp, actually. You don't really need to know ant coding to use emacs 
(I don't recall doing any programming at least in the last ten years 
or so).

Then again, I learned to use emacs some time early 1986, so your 
milage may well vary.

The GNU version for OS X which runs windowing is really nice with the 
one irritation that it uses emacs cut/paste/etc  control keys rather 
than mac ones (so paste is ctrl-y, for example). Before someone pops 
up with "why would they do that?" remember most of the emacs 
control-key bindings date back to the TOPS-10 days, so they probably 
predate Unix, let alone the Macintosh.
---
Andy Holyer, Technical stuff
Hedgehog Broadband, 11 Marlborough Place Brighton BN1 1UB
08451 260895 x 241


---
Andy Holyer, Technical stuff
Hedgehog Broadband, 11 Marlborough Place Brighton BN1 1UB
08451 260895 x 241

Re: BBEdit 8.0

[Peter N Lewis]

At 14:50 +1000 10/9/04, John Horner wrote:
Multi-file regular expression find & replace functionality, with 
nameable saveable expressions
That's the killer-app feature for me. I could actually say that I 
think it's BBEdit that gave me my first glimpse of the power of Perl.
Also, if you're a Perl & BBEdit user and haven't already, check out 
the BBEdit  Help -> Grep reference, it is a very useful reference for 
all the PCRE stuff, especially useful for things in the Advanced Grep 
Topics section like zero width  negative lookbehind assertions (which 
if you're like me you can never remember what sequence of line noise 
they might correspond to).

BBEdit is a very powerful text editor, but where it really out shines 
other text editors is its attention to detail (like handling a file 
being renamed underneath it and updating as the file changes, and 
such) and the way it handles multiple files (I like the Window 
palette, but now also with multiple documents per window), especially 
for things like multifile find & replace

Enjoy,
   Peter.
--
<http://www.stairways.com/>  <http://download.stairways.com/>

Re: BBEdit 8.0

[John Horner]

Multi-file regular expression find & replace functionality, with 
nameable saveable expressions
That's the killer-app feature for me. I could actually say that I 
think it's BBEdit that gave me my first glimpse of the power of Perl.

I use BBEdit literally every day for both HTML and Perl. It's got a 
nice plug-in architecture for compiled things like BBTidy, HTML 
tidying specially compiled for BBEdit, 
http://www.denison.edu/websrv/tutorials/tools/bbTidy.html, but I do 
Perl tidying via it's unix script architecture, whereby you can just 
add PerlTidy to a certain folder and then access that script from a 
menu.

P.S. The science fiction author Cory Doctorow wrote on a blog the 
other day that he's written all his *novels* in BBEdit, which seems 
rather strange to me, but what the hell, it's another note in its 
favour.

Re: BBEdit 8.0

[Ken Williams]

On Sep 9, 2004, at 8:54 PM, Doug McNutt wrote:
I am told, by my son, that the best replacement for MPW in OS neXt is 
really emacs but it requires that I learn smalltalk or something 
similar and, though I have read the book, I just ain't there. X11 
isn't that easy to use either with my four monitors.
I think there are a few mismatches in that paragraph.  I think MPW is 
most analogous to the shell itself, not to emacs.  I'm a happy longtime 
"power-user" of emacs, though I've never taught myself Lisp (which is 
what you meant to say, not Smalltalk).  I just use emacs for editing 
the text, and when I want to run commands I hit control-z and run a 
perl one-liner, or a 'wc' command, or whatever.  Then, since I have 
"bindkey ^Z run-fg-editor" in my .login file, I just hit control-z 
again to drop me back into my editor.  I almost never use emacs' shell 
integration, or write lisp functions, because I find the parent shell a 
more powerful tool.  And this way I get the environment benefits you 
mentioned too.

I'm not sure why X11 got mentioned there either, since you can use 
emacs & the shell without X11 (it's probably been months since I used 
X11 under OS X).

When I'm working with text that's heavily structured, like code or 
delimited data files, I usually plunge into the shell & emacs.  For 
other stuff I usually fire up BBEdit.  Getting comfortable with both is 
really handy. =)

 -Ken

Re: BBEdit 8.0

[Doug McNutt]

At 19:41 -0500 9/9/04, Ian Ragsdale wrote:
>Shell "worksheets" (allows easy editing & running of shell commands)

And there is by far the most important item. When the MacPerl port ran as an MPW tool 
it looked a whole lot like UNIX perl and you could run it from a command line, with 
arguments, and redirect output to another open window or to a file. Any open window, 
if it contained "shell" commands, could be invoked as a tool by simply naming it.

I am told, by my son, that the best replacement for MPW in OS neXt is really emacs but 
it requires that I learn smalltalk or something similar and, though I have read the 
book, I just ain't there. X11 isn't that easy to use either with my four monitors.

BBEdit worksheets are still fairly new and I really hope they will migrate more and 
more closely to either MPW or emacs.  As of now even emacs is not a real shell having 
to pass commands to the user's chosen shell. That makes handling the environment a 
pain just as it is in BBEdit. Each open document has its own associated shell process 
which doesn't talk to the others. MPW was a shell, of sorts, but the underlying 
operating system didn't have shells so the point is moot.

As of version 8 you cannot save a working BBEdit worksheet as an executable perl 
script. You must first convert to a normal BBEdit document and save that while adding 
the appropriate shebang line and executable permission bits. (Yes. you can muck with 
OS 9 file type and creator codes but it's not approved.)

It is so much easier to select a few lines of text and execute them than it is to play 
keyboard games with history arrays. . .  I wax happy about the concept but I miss OS 9 
and MPW.

BBEdit is the best choice right now. Every once in a while there is a burst of 
activity requesting a Carbon version of MPW. Should Apple decide to release the source 
code and provide some kernel hooks for intercepting read and write requests from 
compiled code it could become a real open-source competitor but BBEdit could easily 
beat it out by incorporating selected content from tcsh, or bash, so that BBEdit 
itself becomes a real boy -- er, a shell -- rather than a wooden one with a long nose..

-- 

-->  Halloween  == Oct 31 == Dec 25 == Christmas  <--

Re: BBEdit 8.0

[Ray Zimmerman]

On Sep 9, 2004, at 8:41 PM, Ian Ragsdale wrote:
Well, I imagine a lot of it's following started during the OS <= 9 
days, when things like vi or emacs weren't really available.  It also 
served as a replacement for things like grep and sed which weren't 
available at the time.  I'd imagine that for many people it's the 
interface - you can accomplish a ton of things that are doable with 
command line tools but that most people don't know how to do.  Here 
are some of the things I find really useful:

Effortless & transparent handling & switching of line endings.
Powerful HTML tools
Shell "worksheets" (allows easy editing & running of shell commands)
Multi-file regular expression find & replace functionality, with 
nameable saveable expressions
Transparent FTP/SFTP support
Easy scriptability and integration with command line tools
And don't forget ...
	multi-file diff, with side-by-side highlighting (integrated with CVS, 
too).
	en-tabbing, de-tabbing
	re-wrapping text
	inserting, removing line prefixes/suffixes
... to name just a few more. I'm sure many/most of these things are 
easily doable by someone who's mastered vi or emacs, but it's the 
learning curve that's kept me from ever doing that.

Ray

Re: BBEdit 8.0

[Ian Ragsdale]

On Sep 9, 2004, at 5:00 PM, Chris Carline wrote:
I'm curious as to the attraction of BBEdit. Coming from a Unix/Windows
background, I find that whilst it seems pretty solid and has some nice
features, it costs at least five times more than any sane person
should be prepared to pay. But even taking that into account, it
actually seems to do *less* (at least for me!) than the free
alternatives that ship by default on OS X (personally, I use Vim).
I know vim, but not super well - what does it do that BBEdit does not?  
I imagine if you already know vi/vim well and have it customized to 
your liking, there's no need to pay for anything else.  Personally, 
I've been using it off & on for about 10 years and still don't know how 
to use most of it's features.  Most of the time when I have advanced 
processing to do I copy the file locally and edit using BBEdit.

OK, so its integration into the enitre OS is generally a lot better
than the "free" stuff, but...
Well, for Mac users that's a huge distinction, especially if you don't 
already know vi or emacs.  There isn't really any learning curve to 
deal with.

So why the attraction? Is it really only old OS <=9 users that use it,
or am I really missing something?
Well, I imagine a lot of it's following started during the OS <= 9 
days, when things like vi or emacs weren't really available.  It also 
served as a replacement for things like grep and sed which weren't 
available at the time.  I'd imagine that for many people it's the 
interface - you can accomplish a ton of things that are doable with 
command line tools but that most people don't know how to do.  Here are 
some of the things I find really useful:

Effortless & transparent handling & switching of line endings.
Powerful HTML tools
Shell "worksheets" (allows easy editing & running of shell commands)
Multi-file regular expression find & replace functionality, with 
nameable saveable expressions
Transparent FTP/SFTP support
Easy scriptability and integration with command line tools

Ian

BBEdit 8.0

[Chris Carline]

On Thu, 9 Sep 2004 15:07:52 -0500, Bill Stephenson <[EMAIL PROTECTED]> wrote:
> Well, first off, I just think it's cool that they implemented a feature
> I requested. But beyond that, it's still cool because it does use the
> built-in apache/perl to accomplish this and it does so with a few less
> clicks (I think, I haven't used it yet) than what you describe above.

I'm curious as to the attraction of BBEdit. Coming from a Unix/Windows
background, I find that whilst it seems pretty solid and has some nice
features, it costs at least five times more than any sane person
should be prepared to pay. But even taking that into account, it
actually seems to do *less* (at least for me!) than the free
alternatives that ship by default on OS X (personally, I use Vim).

OK, so its integration into the enitre OS is generally a lot better
than the "free" stuff, but...

So why the attraction? Is it really only old OS <=9 users that use it,
or am I really missing something?

Re: BBEdit 8.0

[Bill Stephenson]

On Sep 3, 2004, at 12:37 AM, Bill Stephenson wrote:
Those BBEdit guys went and implemented another of my "wish list" 
feature requests! Remember the one about a button that allowed you to 
view output from a perl script in a browser? It's apparently in 8.0, 
as well as some other pretty cool new features.
On Sep 9, 2004, at 2:06 PM, Sherm Pendley wrote:
With Mac OS X, I have a real Apache install to work with. I can edit 
CGI scripts and mod_perl handlers in-place, and simply cmd-tab to 
Safari and reload the page. I can configure Console.app to 
automagically pop itself to the front of the window stack whenever 
anything gets appended to Apache's (or some other) error log.

I haven't looked at the whole feature list, but this one particular 
feature sounds like it's too late to be useful. All by itself, it 
would have been worth the upgrade price five years ago, when I was 
using BBEdit 5 on Mac OS 8.6. But now... why should I switch to using 
a CGI simulation, when the Real Thing (tm) is installed by default 
with the OS, and so smoothly integrated into the environment?

sherm--
Well, first off, I just think it's cool that they implemented a feature 
I requested. But beyond that, it's still cool because it does use the 
built-in apache/perl to accomplish this and it does so with a few less 
clicks (I think, I haven't used it yet) than what you describe above.

BTW, I just figured out yesterday that you could monitor the Apache 
error_log with the Console. That's a handy thing to know about. I've 
been using the Terminal to tail the log file all this time :(

Bill

Re: BBEdit 8.0

[Sherm Pendley]

On Sep 3, 2004, at 12:37 AM, Bill Stephenson wrote:
Those BBEdit guys went and implemented another of my "wish list" 
feature requests! Remember the one about a button that allowed you to 
view output from a perl script in a browser? It's apparently in 8.0, 
as well as some other pretty cool new features.
With Mac OS X, I have a real Apache install to work with. I can edit 
CGI scripts and mod_perl handlers in-place, and simply cmd-tab to 
Safari and reload the page. I can configure Console.app to 
automagically pop itself to the front of the window stack whenever 
anything gets appended to Apache's (or some other) error log.

I haven't looked at the whole feature list, but this one particular 
feature sounds like it's too late to be useful. All by itself, it would 
have been worth the upgrade price five years ago, when I was using 
BBEdit 5 on Mac OS 8.6. But now... why should I switch to using a CGI 
simulation, when the Real Thing (tm) is installed by default with the 
OS, and so smoothly integrated into the environment?

sherm--

Re: BBEdit 8.0

[Chuck Rice]

At 11:37 PM -0500 9/2/04, Bill Stephenson wrote:
Those BBEdit guys went and implemented another of my "wish list" 
feature requests! Remember the one about a button that allowed you 
to view output from a perl script in a browser? It's apparently in 
8.0, as well as some other pretty cool new features.

They also mention integration with "Affrus". I tried out a demo a 
while back but haven't kept up on it. Anyone here using Affrus on a 
regular basis?

Bill Stephenson

I was using it. Liked it a lot, but it is currently incompatible with 
the version of Mac OS that I am running. If you are at Mac OSX 10.3.x 
I would recommend it, even though I have not been able to use it in 
several months. -Chuck-

BBEdit 8.0

[Bill Stephenson]

Those BBEdit guys went and implemented another of my "wish list" 
feature requests! Remember the one about a button that allowed you to 
view output from a perl script in a browser? It's apparently in 8.0, as 
well as some other pretty cool new features.

They also mention integration with "Affrus". I tried out a demo a while 
back but haven't kept up on it. Anyone here using Affrus on a regular 
basis?

Bill Stephenson

Re: [OT] Old BBEdit question

[Chris Devers]

On Sun, 23 Nov 2003, wren thornton wrote:

>  --- Thilo Planz <[EMAIL PROTECTED]> wrote:

> > Another more light-weight (and very Mac OS X-like) alternative could
> > be the award-winning SubEthaEdit. It is not so feature-rich, but it
> > does CSS-syntax-high-lighting.
>
> I'll have to look into that :)

The cool thing about SubEthaEdit (nee Hydra) is the Rendezvous-enabled
collaborative editing features. The editor isn't [yet?] as full-featured
as say BBEdit, Vim, or Emacs, but that feature alone is interesting enough
to make SubEthaEdit interesting.

This feature seems very good for any kind of XP peer programming -- which
I'm sure is why it's there in the first place -- but you can also use it
for spontaneous editing & synchronization of a file (like, say, a config
file) across multiple machines. Useful trick, sometimes.

I'm curious if the Barebones folks are thinking of "borrowing" that
feature for a future version of BBEdit... :)



-- 
Chris Devers

Re: [OT] Old BBEdit question

[wren thornton]

--- Jim Correia <[EMAIL PROTECTED]> wrote:
> 4.5.3 doesn't support language plug-ins (that
> capability was added 
> later.) Even so, I am unaware of third party CSS
> modules.

Okay, thanks. I could just set it to plain-text,
shouldn't be too annoying.

--- Jim Correia <[EMAIL PROTECTED]> wrote:
> If you own a copy of 4.5.3 you are eligible for
> upgrade pricing which 
> is substantially cheaper than retail.  (I don't know
> if this fits into 
> your budget or not.)

I'll have to look into that again, I forget how much
the upgrade costed.


--- Thilo Planz <[EMAIL PROTECTED]>
wrote:
> I know everyone has his favorite editor and that the
> matter is an 
> almost religious one, but if you are looking for a
> free and powerful 
> text editor to replace your proven, old BBEdit
> 4.5.3, you should have a 
> look at JEdit (http://jedit.org). It rocks.

I've looked at jedit before and recall not being
particularly enthused by it. I've switched my
favourite browser in the past, so that's not all there
is to it, but I am a big fan of BBEdit. Recently I've
come to see the merits of TextEdit (OSX's SimpleText),
but I wonder how much of that is just because it's a
native X program rather than running under Classic...

--- Thilo Planz <[EMAIL PROTECTED]>
wrote:
> Another more light-weight (and very Mac OS X-like)
> alternative could be 
> the award-winning SubEthaEdit. It is not so
> feature-rich, but it does 
> CSS-syntax-high-lighting.

I'll have to look into that :)

~wren

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

[OT] Old BBEdit question

[Thornton]

Okay, so I've been messing around with my website
lately and in the transition to it being database
driven, part of it is going over to CSS. I have an old
version of BBEdit (4.5.3 on macclassic) and I was
wondering if someone has made a CSS "language" to get
the colors to highlight correctly. I'd get a newer
version of the program if it didn't cost so darn much
(and if I weren't such a poor college student), so
that isn't really an option.

~wren

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: BBEdit-Perl confusion

[drieux]

On Thursday, Oct 16, 2003, at 06:56 US/Pacific, Vic Norton wrote:

I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl  
5.8.0
resides in the "/opt/local/bin" directory, and this directory is at the
beginning of $PATH. Everything works well except that BBEdit seems  
rather
confused. Any suggestions as to how to rectify this confusion would be
appreciated.
p0: have you set up a

	$HOME/.MaxOSX/environment.plist

that would contain say:





PATH
  
/opt/local/bin:/home/drieux/bin:/usr/local/bin:/usr/bin:/bin:/usr/ 
local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin
MANPATH
 
/home/drieux/man:/usr/local/share/man:/usr/share/man



This way the Aqua GUI would be launched knowing about your alternative
directory structure. bbedit is probably picking up a 'default' path
from the GUI when you launch it, hence would most likely be running
the 'default' perl from /usr/bin/perl.
p1: it is interesting that the 'run in terminal' option would
be invoking an alternative version of perl... DUH! hold on, IF
bbedit started with what it thought was the definition, then it
would have invoked perl on the file
	perl 

hence it would have been the /usr/bin/perl (???) version vice
the 'first in the path found' version of perl.


ciao
drieux
---

Re: BBEdit-Perl confusion

[Michael Maibaum]

On Friday, October 17, 2003, at 02:20  am, Doug McNutt wrote:

At 16:12 -0700 10/16/03, Ingles, Juan W. wrote:
I wonder: Is this because
/opt/local/bin/perl   points to the perl 5.6 binary
or
5.6 binary path is hard coded in BBEdit
I don't have any /opt/local/bin/. None was created by the CPAN perl 
5.8 install in July 2002

which perl
on the terminal will tell you what binary you are launching
It just says /usr/bin/perl and says nothing about what it links to.


FWIW (as the maintanier of the dports perl port) We deliberately do not 
replace the system (/usr/bin/perl) binary. If you want to use perl 
5.8.x via darwinports as your 'system' perl you should remove 
/usr/bin/perl and replace it with a symlink to ${prefix}/bin/perl 
(usually /opt/local/bin/perl).

I've been meaning to add a 'switch_perl' shell script similar to the 
one used in freebsd to semi-automate this for those that want it.

Also, I've just updated the perl port to 5.8.1, with the previously 
discussed fix for the DBD::mysql issues.

hth

Michael

--
Michael Maibaum
internet: [EMAIL PROTECTED]|http://mike.maibaum.org
voice: [m] 07958 604025|
--
Michael Maibaum
internet: [EMAIL PROTECTED]|http://mike.maibaum.org
voice: [m] 07958 604025|

RE: BBEdit-Perl confusion

[Doug McNutt]

At 16:12 -0700 10/16/03, Ingles, Juan W. wrote:
>I wonder: Is this because
>/opt/local/bin/perl   points to the perl 5.6 binary
>or
>5.6 binary path is hard coded in BBEdit

I don't have any /opt/local/bin/. None was created by the CPAN perl 5.8 install in 
July 2002

> > which perl
>on the terminal will tell you what binary you are launching

It just says /usr/bin/perl and says nothing about what it links to.

When I installed 5.8 I had to recreate the link for /usr/bin/perl manually and that 
fixed up almost everything but BBEdit 6.x was in vogue at the time and worksheets were 
brand new.

-- 
-->  There are 10 kinds of people:  those who understand binary, and those who don't 
<--

Re: BBEdit-Perl confusion

[Conrad Schilbe]

On 10/16/03 5:12 PM, "Ingles, Juan W." <[EMAIL PROTECTED]> wrote:

> I wonder: Is this because
> /opt/local/bin/perl   points to the perl 5.6 binary
> or 
> 5.6 binary path is hard coded in BBEdit
> 
> 
> 
>> which perl
> on the terminal will tell you what binary you are launching
> 
> 
> 
> ( not currently at my machine to check )
> juan
> 
> -Original Message-
> From: Vic Norton [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 16, 2003 2:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: BBEdit-Perl confusion
> 
> I guess there is no fix right now.
> 
> But actually the bug is somewhat convenient. Now a BBEdit script
> starting with
>#!/opt/local/bin/perl -w
># Perl 5.8
> uses Perl 5.8.0 with its @INC list if "Run" from BBEdit and
> uses Perl 5.6.0 with a different @INC list if "Run in Terminal".
> 
> It's not all bad---though it is a bit confusing.
> 
> Regards,
> 
> Vic
> 
> At 12:03 PM -0400 10/16/03, Bare Bones Software Technical Support wrote:
>> There is a bug in BBEdit where run in terminal hard codes the path
>> to perl as /usr/bin/perl instead of taking the other usual steps to
>> choose which interpreter to run. I have a bug logged and this will
>> be corrected for the next release.
> 
> At 9:56 AM -0400 10/16/03, Vic Norton wrote:
>> I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
>> DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl
> 5.8.0
>> resides in the "/opt/local/bin" directory, and this directory is at the
>> beginning of $PATH. Everything works well except that BBEdit seems
> rather
>> confused. Any suggestions as to how to rectify this confusion would be
>> appreciated.


I have now also found that running this command in Bbedit:

print `which perl`;

Produces the following error:

"MANPATH: Undefined variable."

That is a very strange error to be produced by that command... I thought
maybe it was a problem using the `` syntax to execute via the shell so I
tried system() syntax, same results... I then thought maybe it was that
bbedit choked on any system command but,

print `echo "test"`;

Worked fine... Very strange must have something to do with a hard coded
environment in perl.

C.

Re: BBEdit-Perl confusion

[Conrad Schilbe]

On 10/16/03 5:12 PM, "Ingles, Juan W." <[EMAIL PROTECTED]> wrote:

> I wonder: Is this because
> /opt/local/bin/perl   points to the perl 5.6 binary
> or 
> 5.6 binary path is hard coded in BBEdit

Would this be in a plist file for BBedit?

C.

> 
> 
> 
>> which perl
> on the terminal will tell you what binary you are launching
> 
> 
> 
> ( not currently at my machine to check )
> juan
> 
> -Original Message-
> From: Vic Norton [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 16, 2003 2:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: BBEdit-Perl confusion
> 
> I guess there is no fix right now.
> 
> But actually the bug is somewhat convenient. Now a BBEdit script
> starting with
>#!/opt/local/bin/perl -w
># Perl 5.8
> uses Perl 5.8.0 with its @INC list if "Run" from BBEdit and
> uses Perl 5.6.0 with a different @INC list if "Run in Terminal".
> 
> It's not all bad---though it is a bit confusing.
> 
> Regards,
> 
> Vic
> 
> At 12:03 PM -0400 10/16/03, Bare Bones Software Technical Support wrote:
>> There is a bug in BBEdit where run in terminal hard codes the path
>> to perl as /usr/bin/perl instead of taking the other usual steps to
>> choose which interpreter to run. I have a bug logged and this will
>> be corrected for the next release.
> 
> At 9:56 AM -0400 10/16/03, Vic Norton wrote:
>> I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
>> DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl
> 5.8.0
>> resides in the "/opt/local/bin" directory, and this directory is at the
>> beginning of $PATH. Everything works well except that BBEdit seems
> rather
>> confused. Any suggestions as to how to rectify this confusion would be
>> appreciated.

RE: BBEdit-Perl confusion

[Ingles, Juan W.]

I wonder: Is this because 
/opt/local/bin/perl   points to the perl 5.6 binary
or 
5.6 binary path is hard coded in BBEdit



> which perl
on the terminal will tell you what binary you are launching



( not currently at my machine to check )
juan

-Original Message-
From: Vic Norton [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 16, 2003 2:46 PM
To: [EMAIL PROTECTED]
Subject: Re: BBEdit-Perl confusion

I guess there is no fix right now.

But actually the bug is somewhat convenient. Now a BBEdit script
starting with
 #!/opt/local/bin/perl -w
 # Perl 5.8
uses Perl 5.8.0 with its @INC list if "Run" from BBEdit and
uses Perl 5.6.0 with a different @INC list if "Run in Terminal".

It's not all bad---though it is a bit confusing.

Regards,

Vic

At 12:03 PM -0400 10/16/03, Bare Bones Software Technical Support wrote:
>There is a bug in BBEdit where run in terminal hard codes the path 
>to perl as /usr/bin/perl instead of taking the other usual steps to 
>choose which interpreter to run. I have a bug logged and this will 
>be corrected for the next release.

At 9:56 AM -0400 10/16/03, Vic Norton wrote:
>I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
>DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl
5.8.0
>resides in the "/opt/local/bin" directory, and this directory is at the
>beginning of $PATH. Everything works well except that BBEdit seems
rather
>confused. Any suggestions as to how to rectify this confusion would be
>appreciated.

Re: BBEdit-Perl confusion

[Vic Norton]

I guess there is no fix right now.

But actually the bug is somewhat convenient. Now a BBEdit script starting with
#!/opt/local/bin/perl -w
# Perl 5.8
uses Perl 5.8.0 with its @INC list if "Run" from BBEdit and
uses Perl 5.6.0 with a different @INC list if "Run in Terminal".
It's not all bad---though it is a bit confusing.

Regards,

Vic

At 12:03 PM -0400 10/16/03, Bare Bones Software Technical Support wrote:
There is a bug in BBEdit where run in terminal hard codes the path 
to perl as /usr/bin/perl instead of taking the other usual steps to 
choose which interpreter to run. I have a bug logged and this will 
be corrected for the next release.
At 9:56 AM -0400 10/16/03, Vic Norton wrote:
I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl 5.8.0
resides in the "/opt/local/bin" directory, and this directory is at the
beginning of $PATH. Everything works well except that BBEdit seems rather
confused. Any suggestions as to how to rectify this confusion would be
appreciated.

Re: BBEdit-Perl confusion

[Doug McNutt]

At 09:56 -0400 10/16/03, Vic Norton wrote:
>I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
>DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl 5.8.0
>resides in the "/opt/local/bin" directory, and this directory is at the
>beginning of $PATH. Everything works well except that BBEdit seems rather
>confused.

BBEdit is almost surely executing perl 5.6 and it's probably because of a hard coded 
path.

I had 5.8 running, with some difficulty, over a year ago from the CPAN distribution 
and it is in /opt/. But I had to remove 5.6 from the other directories. It was an 
interesting experience while I learned about gzip and tar to preserve my options.

You'll be OK after that so long as the link in /usr/bin/perl points to the new 
version. Some have complained about Apple's installer requiring the old perl 5.6 but 
it has never bitten me.

-- 
-->  There are 10 kinds of people:  those who understand binary, and those who don't 
<--

BBEdit-Perl confusion

[Vic Norton]

I have recently installed Perl 5.8.0 on my iMac via "PortsManager" from
DarwinPorts <http://www.opendarwin.org/projects/darwinports/>. Perl 5.8.0
resides in the "/opt/local/bin" directory, and this directory is at the
beginning of $PATH. Everything works well except that BBEdit seems rather
confused. Any suggestions as to how to rectify this confusion would be
appreciated.
Here is an example of BBEdit's confusion.

In Terminal the command
   % perl -e 'for (@INC) { print "$_\n" }'
produces
   /opt/local/lib/perl5/5.8.0/darwin
   /opt/local/lib/perl5/5.8.0
   /opt/local/lib/perl5/site_perl/5.8.0/darwin
   /opt/local/lib/perl5/site_perl/5.8.0
   /opt/local/lib/perl5/site_perl
   .
When "Run" from BBEdit the script
   #!/opt/local/bin/perl -w
   for (@INC) { print "$_\n" }
produces exactly the same output in the "Unix Script Output" window.
However, when this script is "Run in Terminal" from BBEdit, the output
is
   /Users/vicnorton/Perl/MyPerl/Misc/tests-work
   /System/Library/Perl/darwin
   /System/Library/Perl
   /Library/Perl/darwin
   /Library/Perl
   /Library/Perl
   /Network/Library/Perl/darwin
   /Network/Library/Perl
   /Network/Library/Perl
   .
 Something seems to be wrong here.

 Any suggestions as to what is going on here and how to rectify it
 would be greatly appreciated.
 Regards,

 Vic

--
*---* mailto:[EMAIL PROTECTED]
| Victor Thane Norton, Jr.
| Mathematician and Motorcyclist
| phone: 419-353-3399
*---* http://vic.norton.name

Re: OT: CVS clients and BBEdit diff tool ...

[Jeff Lowrey]

At 5:57 PM +1100 12/3/02, Ken Williams wrote:

On Tuesday, December 3, 2002, at 05:07  PM, Rob Barris wrote:


Could someone use Inline.pm to talk to the Carbon API and the 
desktop database?  Then you could look up any app by its creator 
code (I would wager).

Have a look at Mac::MoreFiles (part of Mac::Carbon), which does exactly this.

 -Ken


Or use an alternate form of the open command in Applescript and let 
the Finder look the app up by it's creator code for you.

Or use the `open` command directly, instead of through AppleScript. 
Or TIMTOWTDI.

-Jeff Lowrey

Re: OT: CVS clients and BBEdit diff tool ...

[Ken Williams]

On Tuesday, December 3, 2002, at 05:07  PM, Rob Barris wrote:


Could someone use Inline.pm to talk to the Carbon API and the desktop 
database?  Then you could look up any app by its creator code (I would 
wager).

Have a look at Mac::MoreFiles (part of Mac::Carbon), which does exactly 
this.

 -Ken

Re: OT: CVS clients and BBEdit diff tool ...

[Rob Barris]

On Monday, December 2, 2002, at 10:01 PM, John Gruber wrote:


Bruce A. Burdick, Jr. <[EMAIL PROTECTED]> wrote on 12/1/02 at 
11:28p:

I had to change 'BBEdit' to 'BBEdit 6.5' to allow this to work in my
environment.

[...]

Naturally, this patch'll probably break other systems. A general 
solution
might try one and then the other.

You could also just change the name of your BBEdit application from
"BBEdit 6.5" to "BBEdit". There's nothing magic about the app's file
name, so this shouldn't break anything. It won't break *compiled*
applescripts, since they store a reference to application, not the
name of the app.

As a general solution for not-yet-compiled applescripts, such as
those embedded in Perl scripts, I'm not sure what to suggest, other
than not including version info in application file names. :^)



Could someone use Inline.pm to talk to the Carbon API and the desktop 
database?  Then you could look up any app by its creator code (I would 
wager).

Rob

Re: OT: CVS clients and BBEdit diff tool ...

[John Gruber]

Bruce A. Burdick, Jr. <[EMAIL PROTECTED]> wrote on 12/1/02 at 11:28p:

> I had to change 'BBEdit' to 'BBEdit 6.5' to allow this to work in my
> environment.
[...]
> Naturally, this patch'll probably break other systems. A general solution
> might try one and then the other.

You could also just change the name of your BBEdit application from
"BBEdit 6.5" to "BBEdit". There's nothing magic about the app's file
name, so this shouldn't break anything. It won't break *compiled*
applescripts, since they store a reference to application, not the
name of the app.

As a general solution for not-yet-compiled applescripts, such as
those embedded in Perl scripts, I'm not sure what to suggest, other
than not including version info in application file names. :^)

-- 
John Gruber |   Daring Fireball: Mac Punditry and Curmudgeonry
[EMAIL PROTECTED]   |http://daringfireball.net

Re: OT: CVS clients and BBEdit diff tool ...

[Ken Williams]

On Thursday, November 28, 2002, at 01:23  AM, Pete Prodoehl wrote:

This may (or may not) work for you, I wrote a script to do a diff with 
two files via the command line, and if they really are different, it 
opens them both in BBEdit.

It's here:

  http://zymm.com/raster/code/src/diffem_pl.txt

I've really been smitten with the FileMerge application (at 
/Developer/Applications/FileMerge), but unfortunately it doesn't seem to 
be scriptable so this kind of wrapper would be tougher to write.

 -Ken

Re: OT: CVS clients and BBEdit diff tool ...

[Bruce A. Burdick, Jr.]

> Jim Correia <[EMAIL PROTECTED]> wrote on 11/27/02 at 9:08a:
> 
>> I'm sure somebody has at some point. I just wrote one here. It isn't a
>> full fledged tool in that it doesn't give you usage and doesn't have an
>> error checking for arguments and such, but if you always supply both
>> arguments and they are valid, it should do the job.
> 
> I wrote something similar a while back, with switches to control
> whether the comparison ignores case and leading/trailing whitespace.
> It also does some rudimentary testing to make sure you pass exactly
> two arguments, and that both arguments are files.
> 
> I cleaned it up with some POD and usage info (and nabbed a few
> improvements from your script and Peter N Lewis's) and put it here:
> 
>   http://daringfireball.net/projects/bbdiff/

Thanks!

I had to change 'BBEdit' to 'BBEdit 6.5' to allow this to work in my
environment.

Here's a patch:

diff -u bbdiff bbdiff.new
--- bbdiff  Sun Dec  1 23:23:34 2002
+++ bbdiff.new  Sun Dec  1 23:24:05 2002
@@ -43,7 +43,7 @@
 $old_file = File::Spec::Unix->rel2abs( $old_file );
 
 my $a_script = qq[
-tell application "BBEdit"
+tell application "BBEdit 6.5"
 set comp_opts to {case sensitive:$case_sensitive, ignore leading
spaces:$ignore_whitespace, ignore trailing spaces:$ignore_whitespace}
 set comp_result to compare POSIX file "$new_file" against POSIX file
"$old_file" options comp_opts
 if differences found of comp_result then


Naturally, this patch'll probably break other systems. A general solution
might try one and then the other.

-B...

Re: OT: CVS clients and BBEdit diff tool ...

[John Gruber]

Jim Correia <[EMAIL PROTECTED]> wrote on 11/27/02 at 9:08a:

> I'm sure somebody has at some point. I just wrote one here. It isn't a 
> full fledged tool in that it doesn't give you usage and doesn't have an 
> error checking for arguments and such, but if you always supply both 
> arguments and they are valid, it should do the job.

I wrote something similar a while back, with switches to control
whether the comparison ignores case and leading/trailing whitespace.
It also does some rudimentary testing to make sure you pass exactly
two arguments, and that both arguments are files.

I cleaned it up with some POD and usage info (and nabbed a few
improvements from your script and Peter N Lewis's) and put it here:

http://daringfireball.net/projects/bbdiff/

-- 
John Gruber
[EMAIL PROTECTED]

Re: OT: CVS clients and BBEdit diff tool ...

[Adrian Howard]

On Wednesday, November 27, 2002, at 03:39  pm, Peder Axensten wrote:


I want to get started with CVS and BBEdit, how to I run a server? 
There's nothing in the BBEdit manual...
Any good sources of info would be appreciated!

If you're doing local development you might find

	http://developer.apple.com/internet/macosx/cvsoverview.html

Of use.

Adrian

Re: OT: CVS clients and BBEdit diff tool ...

[Peter N Lewis]

BBEdit diff:

I want a bbdiff command-line program. Something that will let me type:

 bbdiff file1 file2

or

 bbdiff dir1 dir2

to initiate a file comparison or multi-file comparison in BBEdit. 
Ideally, Bare Bones would include something like this along side the 
bbedit command-line tool, but I was wondering if anyone has created 
(or could easily create) such a tool via a Perl script making some 
AppleScript calls or something?

bbedit-compare.pl:

#!/usr/bin/perl

use warnings;
use strict;

use File::Spec::Unix;

my $file1 = shift or Usage();
my $file2 = shift or Usage();

compare_in_bbedit( $file1, $file2 );

sub Usage {
  print STDERR "Usage: bbedit-compare.pl file1 file2\n";
  exit( 1 );
}

sub compare_in_bbedit {
  my( $file1, $file2 ) = @_;

  $file1 = File::Spec::Unix->rel2abs( $file1 );
  $file2 = File::Spec::Unix->rel2abs( $file2 );

  do_osa_script( <
tell app "BBEdit"
  compare POSIX file "$file1" against POSIX file "$file2"
  activate
end tell
EOM

}

sub do_osa_script {
  my( $script ) = @_;

  my $fh;
  open( $fh, "| /usr/bin/osascript >/dev/null" ) or die "cant open 
osascript $!";
  print $fh $script;
  close( $fh );
}

Enjoy,
   Peter.

--
<http://www.interarchy.com/>  <http://download.interarchy.com/>

Re: OT: CVS clients and BBEdit diff tool ...

[Ray Zimmerman]

At 9:08 AM -0500 11/27/02, Jim Correia wrote:

On Wednesday, November 27, 2002, at 08:42  AM, Ray Zimmerman wrote:

BBEdit diff:

I want a bbdiff command-line program. Something that will let me type:

 bbdiff file1 file2

or

 bbdiff dir1 dir2

to initiate a file comparison or multi-file comparison in BBEdit. 
Ideally, Bare Bones would include something like this along side 
the bbedit command-line tool, but I was wondering if anyone has 
created (or could easily create) such a tool via a Perl script 
making some AppleScript calls or something?

I'm sure somebody has at some point. I just wrote one here. It isn't 
a full fledged tool in that it doesn't give you usage and doesn't 
have an error checking for arguments and such, but if you always 
supply both arguments and they are valid, it should do the job.




Share and enjoy.


Sweet ... thanks. Isn't OS X great!

--
 Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
  Sr Research  /   phone: (607) 255-9645  /  Cornell University
   Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: OT: CVS clients and BBEdit diff tool ...

[Ray Zimmerman]

At 9:08 AM -0500 11/27/02, Jim Correia wrote (regarding my comments 
on MacCVS Pro):
I think the problem is more than line feeds. The repository file 
gets written out as (this may be wrong since it is from memory) 
server:blahblahblah for an ssh type repository when the command line 
cvs expects :ext:blahblahblah.

Ah ... I was using pserver, which seemed to work OK as soon as I 
changed the CRs to LFs.

--
 Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
  Sr Research  /   phone: (607) 255-9645  /  Cornell University
   Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: OT: CVS clients and BBEdit diff tool ...

[Jim Correia]

On Wednesday, November 27, 2002, at 10:39  AM, Peder Axensten wrote:


I want to get started with CVS and BBEdit, how to I run a server?  
There's nothing in the BBEdit manual...
Any good sources of info would be appreciated!

Setting up a server is beyond the scope of the BBEdit manual I'm afraid.

We put up some FAQs yesterday.

<http://www.barebones.com/cgi-bin/faq/ 
faqgroup.pl?BBEdit_Features#Features_-_1>

To set up a "server" that you can do CVS over ssh with is relatively  
easy. First, turn on the sshd daemon on the machine. Setup a CVS  
repository. (cvs init - see cvs manual - FWIW the little O'Reilly  
pocket reference for about $10 is quite helpful.). Import a project,  
then check out into a sandbox and you are off to the races. (This all  
assumes a propert CVS_RSH = ssh and CVSROOT =  
:ext:user@host:/path/to/repository)

Setting up a pserver is a bit more involved because you've got to get  
xinetd or inetd listening properly, but if you can use ssh you probably  
don't want to use pserver since everything is cleartext.


Jim


--
Jim Correia
[EMAIL PROTECTED]

Re: OT: CVS clients and BBEdit diff tool ...

[Peder Axensten]

I want to get started with CVS and BBEdit, how to I run a server? 
There's nothing in the BBEdit manual...
Any good sources of info would be appreciated!

/Peder

Re: OT: CVS clients and BBEdit diff tool ...

[Pete Prodoehl]

This may (or may not) work for you, I wrote a script to do a diff with 
two files via the command line, and if they really are different, it 
opens them both in BBEdit.

It's here:

  http://zymm.com/raster/code/src/diffem_pl.txt


Pete


Ray Zimmerman wrote:
 for Perl development on OS X, of course  :-)
[snip]
BBEdit diff:

I want a bbdiff command-line program. Something that will let me type:

 bbdiff file1 file2

or

 bbdiff dir1 dir2

to initiate a file comparison or multi-file comparison in BBEdit. 
Ideally, Bare Bones would include something like this along side the 
bbedit command-line tool, but I was wondering if anyone has created (or 
could easily create) such a tool via a Perl script making some 
AppleScript calls or something?

Re: OT: CVS clients and BBEdit diff tool ...

[Jim Correia]

On Wednesday, November 27, 2002, at 08:42  AM, Ray Zimmerman wrote:


I really like Mac CVS Pro, and have been using it under OS 9 and OS X 
as my CVS client. Now, as I'm moving more exclusively to OS X with 
it's command-line cvs, and with the release of BBEdit 7 with it's cvs 
integration, I'd really like to be able to use any of the 3 (Mac CVS 
Pro, command-line cvs, BBEdit cvs) on the same checked out source 
tree. The problem I found is that Mac CVS Pro (2.7d3) uses CR line 
endings in files inside its CVS directories (Entries, Repository, 
Root, etc) which doesn't work with the command-line cvs (and therefore 
BBEdit).

I think the problem is more than line feeds. The repository file gets 
written out as (this may be wrong since it is from memory) 
server:blahblahblah for an ssh type repository when the command line 
cvs expects :ext:blahblahblah.


BBEdit diff:

I want a bbdiff command-line program. Something that will let me type:

 bbdiff file1 file2

or

 bbdiff dir1 dir2

to initiate a file comparison or multi-file comparison in BBEdit. 
Ideally, Bare Bones would include something like this along side the 
bbedit command-line tool, but I was wondering if anyone has created 
(or could easily create) such a tool via a Perl script making some 
AppleScript calls or something?

I'm sure somebody has at some point. I just wrote one here. It isn't a 
full fledged tool in that it doesn't give you usage and doesn't have an 
error checking for arguments and such, but if you always supply both 
arguments and they are valid, it should do the job.

(Note that I am not a perl hacker, so there may be a more perlish way 
to do it.)

#!/usr/bin/perl

use warnings;
use strict;

use Cwd;

my $file1 = shift;
my $file2 = shift;

$file1 = cwd . "/" . $file1 if ($file1 !~ m|^/|);
$file2 = cwd . "/" . $file2 if ($file2 !~ m|^/|);

my $script = qq(
set f1 to posix file "$file1"
set f2 to posix file "$file2"
tell application "BBEdit"
	activate
	compare (f1 as alias) against (f2 as alias)
end tell
return ""
);

system("/usr/bin/osascript", "-e", $script);

Share and enjoy.

Jim

OT: CVS clients and BBEdit diff tool ...

[Ray Zimmerman]

 for Perl development on OS X, of course  :-)

CVS client:

I really like Mac CVS Pro, and have been using it under OS 9 and OS X 
as my CVS client. Now, as I'm moving more exclusively to OS X with 
it's command-line cvs, and with the release of BBEdit 7 with it's cvs 
integration, I'd really like to be able to use any of the 3 (Mac CVS 
Pro, command-line cvs, BBEdit cvs) on the same checked out source 
tree. The problem I found is that Mac CVS Pro (2.7d3) uses CR line 
endings in files inside its CVS directories (Entries, Repository, 
Root, etc) which doesn't work with the command-line cvs (and 
therefore BBEdit). So ... to the question ... does anyone here have a 
build of MacCVS Pro that fixes this issue? Does anyone know if it's 
still being developed/maintained? I've tried, so far unsuccessfully, 
to contact the authors.
	http://www.maccvs.org/
	http://www.sourceforge.net/projects/maccvspro/
Or maybe, someone has a different favorite GUI CVS client they'd like 
to recommend?


BBEdit diff:

I want a bbdiff command-line program. Something that will let me type:

 bbdiff file1 file2

or

 bbdiff dir1 dir2

to initiate a file comparison or multi-file comparison in BBEdit. 
Ideally, Bare Bones would include something like this along side the 
bbedit command-line tool, but I was wondering if anyone has created 
(or could easily create) such a tool via a Perl script making some 
AppleScript calls or something?

--
 Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
  Sr Research  /   phone: (607) 255-9645  /  Cornell University
   Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: BBEdit 7.0 - Not Impressed

[Chris Nandor]

In article ,
 [EMAIL PROTECTED] (Kee Hinckley) wrote:

> At 11:29 PM -0500 11/13/02, Chris Nandor wrote:
> >In article <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED] (_brian_d_foy) wrote:
> >
> >>  i'll have to see about this CVS tool thing.  i'm dubious.
> >
> >It really rocks.  It's fairly simple, but it works great.  I really only
> >want to do a few things with CVS in my text editor: commit and diff.
> 
> Local CVS-only, or remote via ssh (with passcode prompting)?

It just uses the command line cvs tool, I think.  I use it with remote 
CVS.  Mine doesn't prompt for the password, since I have ssh-agent set 
up, but yeah.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: BBEdit 7.0 - Not Impressed

[Kee Hinckley]

At 11:29 PM -0500 11/13/02, Chris Nandor wrote:

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (_brian_d_foy) wrote:


 i'll have to see about this CVS tool thing.  i'm dubious.


It really rocks.  It's fairly simple, but it works great.  I really only
want to do a few things with CVS in my text editor: commit and diff.


Local CVS-only, or remote via ssh (with passcode prompting)?

I keep upgrading to new BBEdit versions, and it is useful enough on 
occasion to make it worth while, but it's not my primary editor.  It 
requires far too much use of the mouse (emacs sequences probably 
help, but I gave up on emacs when my pinky literally refused to move 
one morning--it's no coincidence that Stallman has to dictate his 
edits to somebody).  Also most of my editing is of Embperl, and 
there's no way in BBEdit to merge syntax modes.  I'd dearly love them 
to make the syntax editing extensible with something like Perl 
itself.  In the meantime, I spend most of my time in vim, where I 
don't need either the mouse *or* the control keys.
--

Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/

I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Re: BBEdit 7.0

[John Siracusa]

On 11/14/02 12:26 AM, Peter N Lewis wrote:
>> Yeah, I considered that, but I figured it'd be mentioned somewhere in the
>> BBEdit docs if I had to go to that length.  Anyway, BBEdit appears to try to
>> contact the correct server, which leads me to believe it is reading my
>> config (or at least some of it).  Or is the hostname in the CVS/ directories
>> somewhere?  Anyway, I'll try futzing with environment.plist tomorrow...
> 
> Yes, once you setup a CVS directory, it no longer needs the CVS ROOT
> (it is in ./CVS/Root & ./CVS/Repository.  You still need the CVS RSH
> setting though, at least if you want it to go through ssh.

Yup, that makes sense, and that was it.  Works fine now, thanks :)

-John

Re: BBEdit 7.0 - Not Impressed

[Mike Schienle]

On Thu, 14 Nov 2002 08:09:43 -0600 Pete Prodoehl wrote:

> 
> jEdit anyone? http://jedit.org/
> 
> Open-source, customizable, hackable, extendable, good community, 
> responsive developers, lots of plugins, multi-platform, etc...
> 
> True, it's slower than BBEdit (since it's written in Java) but it's also 
> more open, if that's important to you.

I plan to upgrade BBEdit tonight or tomorrow as soon as I hunt down the
license keys. However, I've been dealing with gvim on a PC (and
occasionally on my Mac) on a fairly regular basis and it offers a
language mode for IDL, something I've been asking the folks at Research
Systems and BareBones to consider for quite a while. It's not the only
reason to choose an editor, but it does make my life a little easier, and 
I'm more than comfortable with vi and its relatives. 

I'll be working at Research Systems in a couple weeks - maybe I can get
something started along those lines one day.

Mike Schienle
Interactive Visuals, Inc.
http://www.ivsoftware.com



-
This message sent using EMUmail -- http://www.emumail.com
-

Jumping through hoops to get E-mail on the road? 
You've got two choices: Join the circus, or use MollyMail.

Molly Mail -- http://www.mollymail.com

Re: BBEdit 7.0 - Not Impressed

[Pete Prodoehl]

jEdit anyone? http://jedit.org/

Open-source, customizable, hackable, extendable, good community, 
responsive developers, lots of plugins, multi-platform, etc...

True, it's slower than BBEdit (since it's written in Java) but it's also 
more open, if that's important to you.


Pete

_brian_d_foy wrote:
In article <[EMAIL PROTECTED]>, Mark S Lowe <[EMAIL PROTECTED]> wrote:



This is BARELY an update. BBEdit is going the way of Interarchy.=20
They've run out of features, or in most causes reached a point where=20
they refuse to program anything difficult, so we're left with features=20=



they have seem rather ossified.

i had a few exchanges with their techies about syntax coloring.  some of my
code doesn't color correctly, and they don't color everything i need.

i could fix things if i wanted to buy CodeWarrior and go through all of
that pain, but i think they should have a better mechanism for that.
why should i have to compile somthing for every language?  i should
be able to write a language description file, like vim has perhaps, 
and that is that.

a few other exchanges on things like that lead me to beleive their
locked into their code base now.

i love the program, and i buy every version, but i do miss some of the
aspects of open source development.  i still wouldn't give it up because
i like it much better than any other editor that has ever existed. :)

i'll have to see about this CVS tool thing.  i'm dubious.

Re: BBEdit 7.0

[Peter N Lewis]

Yeah, I considered that, but I figured it'd be mentioned somewhere in the
BBEdit docs if I had to go to that length.  Anyway, BBEdit appears to try to
contact the correct server, which leads me to believe it is reading my
config (or at least some of it).  Or is the hostname in the CVS/ directories
somewhere?  Anyway, I'll try futzing with environment.plist tomorrow...


Yes, once you setup a CVS directory, it no longer needs the CVS ROOT 
(it is in ./CVS/Root & ./CVS/Repository.  You still need the CVS RSH 
setting though, at least if you want it to go through ssh.

(Disclosure triangles? "Possibly Anarchie 4.0" --Peter N Lewis, 12/99)
(glad to see they finally made it ;)


Yeah, must be one of those features we've run out of, or maybe 
something not too difficult we could implement ;-)
   Peter.

--
<http://www.interarchy.com/>  <http://download.interarchy.com/>

Re: BBEdit 7.0

[_brian_d_foy]

In article , Peter N Lewis 
<[EMAIL PROTECTED]> wrote:

> At 14:18 -0500 13/11/02, John Siracusa wrote:
> >On 11/13/02 11:46 AM, Adrian Howard wrote:
> >>  And CVS support too! Excellent!
> >
> >Hrm, not so excellent for me so far...it just hangs with the "connecting"
> >dialog box and then fails.  CVS works fine from the command line.  Maybe
> >BBEdit isn't picking up my CVS environment variables?  I thought there'd be
> >someplace to set them in the BBEdit prefs, but I haven't found it yet...
> 
> Where are your environment variables configured?
> 
> For BBEdit to have them, they probably need to be in:
> 
> ~/.MacOSX/environment.plist

indeed.  i talked about this recently on use.perl

   http://use.perl.org/~brian_d_foy/journal/8915

Re: BBEdit 7.0

[_brian_d_foy]

In article <[EMAIL PROTECTED]>, John Siracusa 
<[EMAIL PROTECTED]> wrote:

>> Yeah, I considered that, but I figured it'd be mentioned somewhere in the
> BBEdit docs if I had to go to that length.  Anyway, BBEdit appears to try to
> contact the correct server, which leads me to believe it is reading my
> config (or at least some of it).  Or is the hostname in the CVS/ directories
> somewhere?  Anyway, I'll try futzing with environment.plist tomorrow...

most of the stuff CVS needs are in the per-directory CVS special directory.
however, CVS by default tries to use RSH.  you probably want to use SSH,
so you have to set the CVS_RSH environment variable.

Re: BBEdit 7.0 - Not Impressed

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (_brian_d_foy) wrote:

> i'll have to see about this CVS tool thing.  i'm dubious.

It really rocks.  It's fairly simple, but it works great.  I really only 
want to do a few things with CVS in my text editor: commit and diff.  
And both are now a simple key-command away; commit brings up a message 
window to type in, and diff brings up a list of revisions to diff 
against (and, of course, takes you to the great BBEdit differences 
windows to view the diff).

I use it for a few other little things, like revision history and 
checking the status, but the ability to do commit and diff is huge for 
me.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: BBEdit 7.0

[John Siracusa]

On 11/13/02 9:43 PM, Peter N Lewis wrote:
> At 14:18 -0500 13/11/02, John Siracusa wrote:
>> On 11/13/02 11:46 AM, Adrian Howard wrote:
>>>  And CVS support too! Excellent!
>> 
>> Hrm, not so excellent for me so far...it just hangs with the "connecting"
>> dialog box and then fails.  CVS works fine from the command line.  Maybe
>> BBEdit isn't picking up my CVS environment variables?  I thought there'd be
>> someplace to set them in the BBEdit prefs, but I haven't found it yet...
> 
> Where are your environment variables configured?
> 
> For BBEdit to have them, they probably need to be in:
> 
> ~/.MacOSX/environment.plist

Yeah, I considered that, but I figured it'd be mentioned somewhere in the
BBEdit docs if I had to go to that length.  Anyway, BBEdit appears to try to
contact the correct server, which leads me to believe it is reading my
config (or at least some of it).  Or is the hostname in the CVS/ directories
somewhere?  Anyway, I'll try futzing with environment.plist tomorrow...

(Disclosure triangles? "Possibly Anarchie 4.0" --Peter N Lewis, 12/99)
(glad to see they finally made it ;)
-John

Re: BBEdit 7.0

[Peter N Lewis]

At 14:18 -0500 13/11/02, John Siracusa wrote:

On 11/13/02 11:46 AM, Adrian Howard wrote:

 And CVS support too! Excellent!


Hrm, not so excellent for me so far...it just hangs with the "connecting"
dialog box and then fails.  CVS works fine from the command line.  Maybe
BBEdit isn't picking up my CVS environment variables?  I thought there'd be
someplace to set them in the BBEdit prefs, but I haven't found it yet...


Where are your environment variables configured?

For BBEdit to have them, they probably need to be in:

~/.MacOSX/environment.plist

Which needs to be something like:






CVSROOT
yourusername@yourhost:/cvs
CVS_RSH
ssh
DISPLAY
localhost
LC_ALL
C
PERL5LIB
/Library/Perl:/Users/yourusername/perl




Changes take effect at login, so you'll need to logout and log back in.

From what I've seen, there are three places you can put environment variables:

~/.MacOSX/environment.plist - used by everything you launch directly.

~/.cshrc or ~/.tcshrc - used by any tcsh shell you launch (including 
remotely accessed ones).  Terminal launched ones probably pick up the 
environment.plist variables, but if you ssh into your Mac from 
another Mac, then probably not.
setenv PERL5LIB /Library/Perl:/Users/yourusername/perl
setenv CVSROOT yourusername@yourhost:/cvs
setenv CVS_RSH ssh
setenv LC_ALL C

crontab -e file - you can also set envrionment variables in your 
crontab which will get used when executing cron actions.
PERL5LIB=/Library/Perl:/Users/yourusername/perl
LC_ALL=C
12 1 * * * perl dosomething.pl

Enjoy,
   Peter.


--
<http://www.interarchy.com/>  <http://download.interarchy.com/>