Re: confusing bullets

[John Delacour]

At 6:21 pm -0500 11/1/04, Vic Norton wrote:

P.S. I tried your script below. I haven't the slightest idea what 
the output means. As I said, a real web bullet is •.
A bullet can be written in valid html code in the real world in half 
a dozen different ways, and that would not be the preferred one 
either, but enough of this.

$f = "/tmp/bullet.html";
open F, ">$f";
print F '•';
`open -a safari $f` ;
JD

Re: Getting a 'Save As' dialog box

[Rick Measham]

Thanks John,

Works a treat!



On 12 Jan 2004, at 03:47 pm, John Delacour wrote:

At 2:51 pm +1100 12/1/04, Rick Measham wrote:

 I used CPAN module Mac::AppleScript and I don't get any reply at all:
RunAppleScript
Further to my last posting, I discover that some applications will not 
behave properly if the tell target is themselves.  Eudora and BBEdit 
6.5 are two examples of apps that hang, but you can run this from the 
Terminal or you can run it from the Terminal with Terminal as the 
target.  It will also work fine with tell self in certain other apps.

#!/usr/bin/perl
use Mac::AppleScript qw(RunAppleScript);
my $asresult  = RunAppleScript <
Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf

Re: Getting a 'Save As' dialog box

[John Delacour]

At 2:51 pm +1100 12/1/04, Rick Measham wrote:

 I used CPAN module Mac::AppleScript and I don't get any reply at all:
RunAppleScript
Further to my last posting, I discover that some applications will 
not behave properly if the tell target is themselves.  Eudora and 
BBEdit 6.5 are two examples of apps that hang, but you can run this 
from the Terminal or you can run it from the Terminal with Terminal 
as the target.  It will also work fine with tell self in certain 
other apps.

#!/usr/bin/perl
use Mac::AppleScript qw(RunAppleScript);
my $asresult  = RunAppleScript <

Re: Getting a 'Save As' dialog box

[Jerry LeVan]

Have you ever looked at Perl/Tk ? It provides a complete GUI for Perl 
under X11.

--Jerry

On Jan 11, 2004, at 10:51 PM, Rick Measham wrote:

Hello People,

I need some help with a perl on OS-X problem. I need to pop up a 'Save 
As' dialog. Basically the same as the one AppleScript gives you when 
you:
	choose file name with prompt "Select a location to save this file" 
default name "Name"

but I need to do this from perl. At first I thought it might be simple:
	$file = `osascript -e 'choose file name with prompt "test1" default 
name "test2"'`;
but that gives me: 0:57: execution error: No user interaction allowed. 
(-1713)

So next I used CPAN module Mac::AppleScript and I don't get any reply 
at all:
	RunAppleScript(qq(choose file name with prompt "test1" default name 
"test2"));

But I figure that somewhere in all this there must be a way to pop up 
such a dialog directly from perl.

How?

Thanks and Cheers!
Rick




Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf

Re: Getting a 'Save As' dialog box

[John Delacour]

At 2:51 pm +1100 12/1/04, Rick Measham wrote:

So next I used CPAN module Mac::AppleScript and I don't get any reply at all:
	RunAppleScript(qq(choose file name with prompt "test1" 
default name "test2"));
I think all you're missing is a tell target.  This works here, though 
painfully slowly as with all these Mac:: things

use Mac::AppleScript qw(RunAppleScript);
RunAppleScript <

Getting a 'Save As' dialog box

[Rick Measham]

Hello People,

I need some help with a perl on OS-X problem. I need to pop up a 'Save 
As' dialog. Basically the same as the one AppleScript gives you when 
you:
	choose file name with prompt "Select a location to save this file" 
default name "Name"

but I need to do this from perl. At first I thought it might be simple:
	$file = `osascript -e 'choose file name with prompt "test1" default 
name "test2"'`;
but that gives me: 0:57: execution error: No user interaction allowed. 
(-1713)

So next I used CPAN module Mac::AppleScript and I don't get any reply 
at all:
	RunAppleScript(qq(choose file name with prompt "test1" default name 
"test2"));

But I figure that somewhere in all this there must be a way to pop up 
such a dialog directly from perl.

How?

Thanks and Cheers!
Rick




Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf

Help! OpenDirectory refuses to add admin acct to LDAP

[Randall Perry]

Did an upgrade from 10.2.6 to 10.3.2 on an Xserve. During upgrade, kept
server as Standalone.

Tried switching to OpenDirectory. It worked, but if I look under users in
the LDAP dir my admin account authentication info I added when switching to
OD (UID 501) isn't there. If I enable showing system users in preferences in
WM I do see the System Administrator account (root), but it will not allow
me to authenticate as root.

Talked to Apple, they told me this problem occurs in the following
situtations when upgrading or switching to OD from standalone:
1) if your ethernet cable is unplugged
2) if you have more than one IP active on a single interface, or you
have a single IP active but it's not the original (first) IP you assigned to
the interface.

So they suggested I switch to Standalone, turn off all Ips except the first,
reboot, switch to OD. That didn't work. So I forced server setup assistant
to run by removing /var/db/.AppleSetupDone and going through the setup
process and choose Open Directory. And the setup app crashed at the end like
it always does. When I rebooted OD was active but there was still no admin
501 account.

So Apple said the next step is to do a clean reinstall. I asked if it's
possible to directly edit the LDAP files to add the admin user. They said it
was but that was beyound the scope of Apple support.

So, if anyone knows how to directly edit the Berkley DB/XML files associated
with OD LPAD to add an admin user so I can use my currently useless LDAP
directory, I'd appreciate it.

Otherwise I've got a painful clean install to do.





-- 
Randall Perry
sysTame

Xserve Web Hosting/Co-location
Website Development/Promotion
Mac Consulting/Sales

http://www.systame.com/

Re: confusing bulltes

[Jim Correia]

On Jan 11, 2004, at 9:55 PM, Peter N Lewis wrote:

When you 'run the script from BBEdit, either directly or "Run in 
Terminal."', what actually happens is BBEdit saves the file in a 
temporary file and then executes it.
Not always. If the editing window is unsaved, or has non-native line 
endings, or a non-native encoding (see below.)

It would seem that BBEdit is saving the temporary file in UTF8 format 
rather than the specified format.
This can be controlled by the checkbox in the Unix Scripting prefs.

Jim

Re: confusing bulltes

[Peter N Lewis]

At 9:02 PM -0500 11/1/04, Vic Norton wrote:
When I write another script to print out the bytes under __DATA__, I see
"A5" if I execute the script from Terminal, and I see "E2 80 A2" if 
I run the script fom BBEdit, either directly or "Run in Terminal." 
But BBEdit can see "A5". It just can't see it as "DATA". If I write 
a script to look for "A5" in the file that contains the single 
option-8 data element and run the script from BBEdit, BBEdit has no 
trouble spotting the A5 at the end of the file.
When you 'run the script from BBEdit, either directly or "Run in 
Terminal."', what actually happens is BBEdit saves the file in a 
temporary file and then executes it.

It would seem that BBEdit is saving the temporary file in UTF8 format 
rather than the specified format.

Actually, check your BBEdit preferences for Text Files: Opening, and 
also Saving.  There is a configuration in there for Default Text 
Encoding and Guessing Text Encoding.  It seems when BBEdit saves the 
temporary file, these are used instead of the current file's text 
encoding.

Enjoy,
   Peter.
--
  

Re: confusing bulltes

[Oliver Schnarchendorf]

On Sun, 11 Jan 2004 21:02:14 -0500, Vic Norton wrote:
> 
> My actual script looks for the pattern "m/\xa5/" in the data. If I 
> make the script executable and run it from the terminal, it finds 
> "A5". If I execute the script from BBEdit, either directly or "Run in 
> Terminal", no "A5" is found.
> 
Okay... I think the problem here is that BBEdit doesn't use your Environmental 
variables.

You can print them with the following one liner

perl -e 'use Data::Dumper; print Dumper (\%ENV);'

Do yourself a favor and put the above perl into a script, run it from the command line 
and run it from BBEdit. If you see differences you might want to read up on the 
.MacOSX/environment.plist file and how it is used.



If you don't want to go through the steps mentioned in the article above, you might 
want to follow the steps in the following use.perl journal entry by brian d foy.



/oliver/

Re: confusing bulltes

[Vic Norton]

I'm sorry for all the confusion. Let me try one last time.

I have a perl file with a single chunk of data produced by typing 
option-8 after __DATA__. So the end of the file looks like this:

__DATA__
option-8
When I look at this file with HexEdit, option-8 appears as "A5".

My actual script looks for the pattern "m/\xa5/" in the data. If I 
make the script executable and run it from the terminal, it finds 
"A5". If I execute the script from BBEdit, either directly or "Run in 
Terminal", no "A5" is found.

When I write another script to print out the bytes under __DATA__, I see
"A5" if I execute the script from Terminal, and I see "E2 80 A2" if I 
run the script fom BBEdit, either directly or "Run in Terminal." But 
BBEdit can see "A5". It just can't see it as "DATA". If I write a 
script to look for "A5" in the file that contains the single option-8 
data element and run the script from BBEdit, BBEdit has no trouble 
spotting the A5 at the end of the file.

Sorry to be such a bore! Now I quit.

Regards,

Vic

Re: confusing bullets

[Vic Norton]

Hi John,

What I meant and sent was what Sherm Pedley called a bullet, namely 
what is produced on a Mac when you type option-8. The unicode 
character is \x{2022}. On web pages it is •.

When I put "bullet • on a web page, open the page in 
Safari, copy the "bullet" from the page, and paste it into to a Mac 
Roman BBEdit text file, I see a bullet that is encoded in the file as 
A5. I can get the same bullet by typing option-8 in the text file.

I now realize that I was only seeing the CA "bullet" before because I 
was showing invisibles in BBEdit. Then the CA character looked like a 
faded bullet. Ordinarily it is invisible.

Regards,

Vic

P.S. I tried your script below. I haven't the slightest idea what the 
output means. As I said, a real web bullet is •.

At 8:37 PM + 1/11/04, John Delacour wrote:
At 1:52 pm -0500 11/1/04, Vic Norton wrote:

 # file0.pl - The data in "file0.pl" is a real bullet,
 #namely A5. But the script "file0.pl" can't
 #find it when run from BBEdit.
Vic, before I spend time testing this, what do you mean by "real 
bullet" namely A5.  Do you mean that we are to replace "\x5" in the 
scripts you posted with Macintosh character "*" and save the scripts 
as Unix without the Encode as Unicode checked ?  There are a lot of 
options and your instructions are far from unambiguous.

I get the feeling you have not yet visited the Unicode page I recommended.

As to BBEdit, it's important to realise that it does not speak 
Unicode.  It uses an interpreter. What you see is not what you get. 
If the interpreter can't convert to mac it prints the raw UTF-8.

If you run this script from BBEdit you will see how "real" your bullet is.

#!/usr/bin/perl
no warnings ;
$f = "/tmp/vicsbullet.html" ;  open  F, ">$f" ;
print "\x{1F00}";  print F "\x{1F00}"; 
print chr 10;  print F chr 13;
print "\xA5";  print F "\xA5";
close F;
`open -a safari $f` ;



JD

Re: confusing bullets

[John Delacour]

At 1:52 pm -0500 11/1/04, Vic Norton wrote:

 # file0.pl - The data in "file0.pl" is a real bullet,
 #namely A5. But the script "file0.pl" can't
 #find it when run from BBEdit.
Vic, before I spend time testing this, what do 
you mean by "real bullet" namely A5.  Do you mean 
that we are to replace "\x5" in the scripts you 
posted with Macintosh character "•" and save the 
scripts as Unix without the Encode as Unicode 
checked ?  There are a lot of options and your 
instructions are far from unambiguous.

I get the feeling you have not yet visited the Unicode page I recommended.

As to BBEdit, it's important to realise that it 
does not speak Unicode.  It uses an interpreter. 
What you see is not what you get.  If the 
interpreter can't convert to mac it prints the 
raw UTF-8.

If you run this script from BBEdit you will see how "real" your bullet is.

#!/usr/bin/perl
no warnings ;
$f = "/tmp/vicsbullet.html" ;  open  F, ">$f" ;
print "\x{1F00}";  print F "\x{1F00}"; 
print chr 10;  print F chr 13;
print "\xA5";  print F "\xA5";
close F;
`open -a safari $f` ;


JD

Re: confusing bullets

[Doug McNutt]

At 13:52 -0500 1/11/04, Vic Norton wrote:
>Now I seem to have resolved the problem--sort of. I believe it's a bug in BBEdit.

I suspect BareBones will call it a feature.

The unwillingness of BBEdit to work on a file without doing things like changing all 
of the line ends has been a pain. It is impossible to edit and save a file that has 
mixed line ends. When looking at a file, even with "show invisibles" enabled, it's 
impossible to see what kind of line end is present. It's also possible that BBEdit is 
preprocessing the UTF* stuff before you get to see it. I usually run to MPW on my 8500 
to handle such things.

BBEdit's HEX dump Tool will allow you to look at  the raw file but, in ordinary 
Editing mode, there is no way to see, for instance, the byte order mark. HEX Dump will 
not allow any editing of the file.

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

Re: confusing bullets

[Vic Norton]

Hi John and Sherm,

Thanks for the info. I have tried your 
experiments and found them very interesting. But, 
in all of your examples, perl and HexEdit see 
exactly the same thing; whereas, in my problem, 
perl and HexEdit were seeing things differently. 
Perl seemed to have double vision.

Now I seem to have resolved the problem--sort of. 
I believe it's a bug in BBEdit. Perhaps you could 
check it out with the following two file/scripts 
(Mac Roman).

=== first file/script ===

 #!/usr/bin/perl -w

 # file0.pl - The data in "file0.pl" is a real bullet,
 #namely A5. But the script "file0.pl" can't
 #find it when run from BBEdit.
 use strict;

 while () {
print "found A5\n" if /\xa5/;
 }
 __DATA__
 *
=== second file/script ===

 #!/usr/bin/perl -w

 # file1.pl - On the other hand, this script has no trouble
 #finding the bullet in the data of "file0.pl",
 #whether or not it is run from BBEdit.
 use strict;
 use FindBin qw($Bin);
 open FILE, "<$Bin/file0.pl";
 while () {
print "found A5\n" if /\xa5/;
 }
 close FILE;
If you create the two files in the same folder 
and make then both executable, then the commands

 $  ./file1.pl
 $  ./file2.pl
produce the same result, "found A5". If you run 
"file1.pl" from BBEdit, you get the "found A5" 
result as well. However, if you open "file0.pl" 
in BBEdit and run it either directly or "in 
Terminal", no output is produced. As far as 
BBEdit is concerned, that 1 byte A5 bullet is now 
3 bytes long. You can find it with the pattern 
"\xe2\x80\xa2". Apparently BBEdit is 
reinterpreting the single byte of data as 3 bytes 
of a "UTF8 encoding with no byte-order mark," to 
quote you, Sherm.

Regards,

Vic

At 12:14 PM + 1/11/04, John Delacour wrote:
At 9:26 pm -0500 10/1/04, Vic Norton wrote:

I'm sorry, John. I was talking figuratively. I didn't mean real bullets.
FIguratively or no, you were right on target 
with your choice.  The bullet is a character in 
the 'macintosh' character set (referred to 
wrongly by the Perl people "MacRoman") which 
does not exist in the widely used (or at least 
declared) charset Latin-1 and has the same 8-bit 
codepoint as the i with diaeresis « ï » in the 
Windows-1252 charset. It is to rebuild this 
Tower of Babel that Unicode was conceived and, 
far too slowly, brought into the computer world 
first in Windows NT and finally in Mac OS X. 
Unicode is a 'good thing' but it requires to be 
learned about and you'll come unstuck pretty 
often if you don't put aside a bit of time to do 
so.



%   perldoc -X Encode | more

SEE ALSO
Encode::Encoding, Encode::Supported, Encode::PerlIO, encoding,
perlebcdic, "open" in perlfunc, perlunicode, utf8, the Perl Unicode
Mailing List <[EMAIL PROTECTED]>
How come Perl sees "C2 A0" whenever HexEdit 
sees "CA" and visa versa? I don't care what 
kind of characters we are talking here. To 
paraphrase Gertrude Stein, "a byte is a byte is 
a byte." At least that's what I thought until 
now.
Gertrude Stein was a character.  Some characters 
are a byte. Some are not, and you have to care.

use strict ;
my $file = "/tmp/file";
#
open FILE, ">:utf8", $file ;
print FILE "\xF0" ;
close FILE ;
#
open FILE, $file ;
print "UTF-8:\t" .   . $/ ;
close FILE;
#
open FILE, ">$file" ;
print FILE "\xF0" ;
close FILE ;
#
open FILE, $file ;
print "MacRoman:\t" .   . $/ ;
close FILE;
exit ;
JD
At 1:45 AM -0500 1/11/04, Sherm Pendley wrote:
On Jan 10, 2004, at 9:26 PM, Vic Norton wrote:

How come Perl sees "C2 A0" whenever HexEdit 
sees "CA" and visa versa? I don't care what 
kind of characters we are talking here. To 
paraphrase Gertrude Stein, "a byte is a byte is 
a byte." At least that's what I thought until 
now.
Like John said - text encoding.

The file you're viewing with HexEdit is most 
likely encoded using MacRoman, or possibly ISO 
8859-1. Internally, Perl uses UTF8 encoding.

Try this: Create a new text file in BBEdit, and 
enter a bullet (opt-8). Save it using the 
default text encoding. HexEdit shows a single 
byte in the file: A5. Now, open the file again, 
and save a copy of it using UTF8 encoding with 
no byte-order mark. HexEdit now shows *three* 
bytes: E2 80 A2. And, you have to tell BBEdit 
what encoding the file uses when you open it - 
without the byte-order mark, BBEdit can't tell 
it's UTF8.

Just for grins, save it again, this time *with* 
the byte-order mark. HexEdit now reports *six* 
bytes in the file: EF BB BF E2 80 A2.

In other words, yes - a byte is a byte is a 
byte. But you're not working with bytes, you're 
working with text. A character is not always a 
byte. It can be several bytes, depending on how 
it's encoded.

sherm--

Re: confusing bullets

[John Delacour]

At 9:26 pm -0500 10/1/04, Vic Norton wrote:

I'm sorry, John. I was talking figuratively. I didn't mean real bullets.
FIguratively or no, you were right on target with 
your choice.  The bullet is a character in the 
'macintosh' character set (referred to wrongly by 
the Perl people "MacRoman") which does not exist 
in the widely used (or at least declared) charset 
Latin-1 and has the same 8-bit codepoint as the i 
with diaeresis « ï » in the Windows-1252 charset. 
It is to rebuild this Tower of Babel that Unicode 
was conceived and, far too slowly, brought into 
the computer world first in Windows NT and 
finally in Mac OS X.  Unicode is a 'good thing' 
but it requires to be learned about and you'll 
come unstuck pretty often if you don't put aside 
a bit of time to do so.



%   perldoc -X Encode | more

SEE ALSO
Encode::Encoding, Encode::Supported, Encode::PerlIO, encoding,
perlebcdic, "open" in perlfunc, perlunicode, utf8, the Perl Unicode
Mailing List <[EMAIL PROTECTED]>

How come Perl sees "C2 A0" whenever HexEdit sees 
"CA" and visa versa? I don't care what kind of 
characters we are talking here. To paraphrase 
Gertrude Stein, "a byte is a byte is a byte." At 
least that's what I thought until now.
Gertrude Stein was a character.  Some characters 
are a byte. Some are not, and you have to care.

use strict ;
my $file = "/tmp/file";
#
open FILE, ">:utf8", $file ;
print FILE "\xF0" ;
close FILE ;
#
open FILE, $file ;
print "UTF-8:\t" .   . $/ ;
close FILE;
#
open FILE, ">$file" ;
print FILE "\xF0" ;
close FILE ;
#
open FILE, $file ;
print "MacRoman:\t" .   . $/ ;
close FILE;
exit ;
JD