Re: File write/read problem
On Wednesday, September 24, 2003, at 10:54 PM, [EMAIL PROTECTED] wrote: Now that sounds like that could be the overarching problem. It would also explain (I thingk) why I can't change the permissions of any of those directories with an ftp client. So if I change the ownership of the cgi-bin (and all the folders associated with the server) to www:www, then I should be able to write to the file. How is that accomplished? Thanks for your help, May I suggest that think of the security implications by making cgi-bin work writeable. It only has to be world executeable NOT more. If you want to write to a file write to a directory outside of cgi-bin in mac osx you might want to use /Users/shared/. If you still want change ownership issue the command 'man chown' in the terminal (without the quotes), for changing file permissions use 'man chmod'. Please Do inform yourself before you change ownership and permissions - you can screw yourself big time. JM2C/h
Re: [OT] OSX privileges question
--- Joel Rees [EMAIL PROTECTED] wrote: This is one of the typical reasons people turn to DBMSs. PostGreSQL would likely be overkill, but MySQL or perhaps even Apple's own FM might help. (I'm pretty sure FM allows storing documents, but I've never done it myself.) I might look into it. Sounds like a pretty big change, which I'm not sure will go over so well. It'd prolly also take some time to set up which is difficult to get since we're running 24/7. I think I might end up just setting all folders to r-x excepting the ones which directly contain files which I'll leave rwx. Not as tight a straitjacket as I was hoping, but it'll have to do. FileMaker Pro should never be used in the way you I think you are describing. What you need to do there is run the [...] Or, at least, that's what I've heard on the 'Filemaker Experts' [EMAIL PROTECTED] list. You might want to sign on there for a while. Thanks for the advice. I'll have to check it out. There're a few other things I'd like to muck around with in FMP too. ~wren __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: File write/read problem
On Wednesday, September 24, 2003, at 10:44 PM, [EMAIL PROTECTED] wrote: OK, that makes perfect sense, but it is not working here. Here is a basic script which, when run, should create a new file called example.txt because it is not there when the open statement is used. #!/usr/bin/perl print Content-type: text/html\n\n; print Creating new file...; my $newtext = newtext from old; open (USER, example.txt); print USER $newtext; close USER; exit; As you've said, it should create the file in the same directory, in this case the cgi-bin, as the script (which is called write.cgi). I run the call the script from the browser and the script runs fine, except, no file is created. I added a || die ($!) at the file open call and add the CGI::CARP qw(fatalToBowser) at the top and get the following. Permission denied at /Library/WebServer/CGI-Executables/write.cgi All the permissions for each of these directories are 755. Something is a miss. So what can I do?! I'm very confused. Who owns the directories? The Web server runs as user www (unless you're not running the stock httpd). That's probably your problem. HTH, Paul. -- Paul Hoffman :: Taubman Medical Library :: Univ. of Michigan [EMAIL PROTECTED] :: [EMAIL PROTECTED] :: http://www.nkuitse.com/
Re: File write/read problem
On Thursday, September 25, 2003, at 12:33 AM, Greenhalgh David wrote: On Wednesday, Sep 24, 2003, at 20:05 Etc/GMT, Ken Williams wrote: Nope. When you open for reading (), it won't be auto-created. It will when you open for writing or appending ( or ). -Ken Not necessarily on every Mac. The same thing happens to me here, opening a file for writing does not create the file. Well then, you didn't succeed in opening it for writing. =) Try the following code, it will either die or create the files, depending on your permissions: --- #!/usr/bin/perl open FH, foo_write or die Can't create foo_write: $!; print FH some data\n; close FH; open FH, foo_append or die Can't create foo_append: $!; print FH some data\n; close FH; --- There should be no variation of this behavior on any platform perl runs on, '' and '' will always create the file first. -Ken
Re: File write/read problem
In just checked the httpd.conf file and, yes, the user/group is set to www/www. So I need to change it to what? Mark - Original Message - From: Paul Hoffman [EMAIL PROTECTED] To: John Delacour [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 5:23 AM Subject: Re: File write/read problem On Wednesday, September 24, 2003, at 10:44 PM, [EMAIL PROTECTED] wrote: OK, that makes perfect sense, but it is not working here. Here is a basic script which, when run, should create a new file called example.txt because it is not there when the open statement is used. #!/usr/bin/perl print Content-type: text/html\n\n; print Creating new file...; my $newtext = newtext from old; open (USER, example.txt); print USER $newtext; close USER; exit; As you've said, it should create the file in the same directory, in this case the cgi-bin, as the script (which is called write.cgi). I run the call the script from the browser and the script runs fine, except, no file is created. I added a || die ($!) at the file open call and add the CGI::CARP qw(fatalToBowser) at the top and get the following. Permission denied at /Library/WebServer/CGI-Executables/write.cgi All the permissions for each of these directories are 755. Something is a miss. So what can I do?! I'm very confused. Who owns the directories? The Web server runs as user www (unless you're not running the stock httpd). That's probably your problem. HTH, Paul. -- Paul Hoffman :: Taubman Medical Library :: Univ. of Michigan [EMAIL PROTECTED] :: [EMAIL PROTECTED] :: http://www.nkuitse.com/
Re: File write/read problem
On Thursday, Sep 25, 2003, at 14:25 Etc/GMT, Ken Williams wrote: On Thursday, September 25, 2003, at 12:33 AM, Greenhalgh David wrote: On Wednesday, Sep 24, 2003, at 20:05 Etc/GMT, Ken Williams wrote: Nope. When you open for reading (), it won't be auto-created. It will when you open for writing or appending ( or ). -Ken Not necessarily on every Mac. The same thing happens to me here, opening a file for writing does not create the file. Well then, you didn't succeed in opening it for writing. =) Try the following code, it will either die or create the files, depending on your permissions: --- #!/usr/bin/perl open FH, foo_write or die Can't create foo_write: $!; print FH some data\n; close FH; open FH, foo_append or die Can't create foo_append: $!; print FH some data\n; close FH; --- There should be no variation of this behavior on any platform perl runs on, '' and '' will always create the file first. -Ken Indeed it ought, and indeed it does on the FreeBSD target host and on my QS, but not on the TiG4. I am sure it is a very obscure permissions thing, though there's never an error in the log file. Mind you, this Powerbook has a record of flakiness so I'm not over-concerned. It's not Perl's fault! Dave
Adding libraries to Perl on Mac OS X
I'm have trouble adding perl libraries to my OS X machine. I've installed the developer tools and the gcc updater from August but when running the command install bundle::CPAN I get make errors. Warning: prerequisite Test::more failed to load: Can't locate Test/More.pm in @INC An r command to CPAN shows Test and Test::Harness as the only Test entries. Kevin
Re: File write/read problem
Mark, Leave the permissions on httpd.conf as they are, in case you're tempted to change them. :-) After you've read this message, I suggest you read up on UNIX permissions -- maybe someone else can recommend a good source of information. The key is that your CGI script runs as user www and group www. All the permissions have to take that into account. I'll describe one way to accomplish what (I think) you want; there may be others. What you need to do is change the owner and/or group of any directories to which your CGI script will be adding files, and of any *existing* files which your CGI script will be modifying. It sounds like you have the following setup: / Library/ WebServer/ CGI-Executables/ write.cgi file1.txt file2.txt ... First, it's not a good idea to create or modify files within the CGI-Executables (a.k.a. cgi-bin) directory, so I would *definitely* put any data files in a separate directory, called (say) CGI-Data: % cd /Library/WebServer % chmod o-w .# make sure permissions on /Library/WebServer are sane % sudo mkdir CGI-Data % ls -l drwxr-xr-x2 root admin 68 Sep 25 11:40 CGI-Data (I'll continue to edit the output of `ls -l' as I've done here.) If there are any existing files to move here, go ahead and move (or copy) them now: % sudo mv file1.txt file2.txt CGI-Data As it stands now, your CGI script won't be able to do anything in this directory or to its files -- you created it as root so, by default, root is its owner. I'm assuming that you want to be able to read and write things in this directory yourself, so what you can do is make yourself the owner and www the group. Let's say by some strange chance your user id is the same as mine, nkuitse: % sudo chown -R nkuitse:www CGI-Data % ls -l drwxr-xr-x 2 nkuitse www 68 Sep 25 12:05 CGI-Data OK, so now you (nkuitse) can do anything you want to do in this folder, and (because of the -R option, which means and do the same to the directory's contents, recursively) you can do anything to the files within it. But your CGI script still can't touch them, because the group permissions are still r-x. That's easy to fix: % chmod -R 775 CGI-Data % ls -l drwxrwxr-x 2 nkuitse www 68 Sep 25 12:05 CGI-Data Note two things: 1. sudo wasn't needed because now you're the owner, and you have write permission (unless you took away write permission from the files you moved, before you moved them) 2. chmod also has an -R option with the same effect as chown's Now all you have to do is modify your script so it writes to ../CGI-Data/file1.txt, etc. instead of just file1.txt, etc. Or you can use absolute paths like /Library/WebServer/CGI-Data/file1.txt if you prefer (this is less portable but that may not matter in your case). If you want to get fancy, you can set up individual subdirectories within CGI-Data, setting the permissions for one so your CGI script can only modify *existing* files, and setting them for the other so your CGI script can modify existing files *and* add files. HTH, Paul. On Thursday, September 25, 2003, at 10:08 AM, Mark Wheeler wrote: In just checked the httpd.conf file and, yes, the user/group is set to www/www. So I need to change it to what? Mark - Original Message - From: Paul Hoffman [EMAIL PROTECTED] To: John Delacour [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 5:23 AM Subject: Re: File write/read problem On Wednesday, September 24, 2003, at 10:44 PM, [EMAIL PROTECTED] wrote: OK, that makes perfect sense, but it is not working here. Here is a basic script which, when run, should create a new file called example.txt because it is not there when the open statement is used. #!/usr/bin/perl print Content-type: text/html\n\n; print Creating new file...; my $newtext = newtext from old; open (USER, example.txt); print USER $newtext; close USER; exit; As you've said, it should create the file in the same directory, in this case the cgi-bin, as the script (which is called write.cgi). I run the call the script from the browser and the script runs fine, except, no file is created. I added a || die ($!) at the file open call and add the CGI::CARP qw(fatalToBowser) at the top and get the following. Permission denied at /Library/WebServer/CGI-Executables/write.cgi All the permissions for each of these directories are 755. Something is a miss. So what can I do?! I'm very confused. Who owns the directories? The Web server runs as user www (unless you're not running the stock httpd). That's probably your problem. HTH, Paul. -- Paul Hoffman :: Taubman Medical Library :: Univ. of Michigan [EMAIL PROTECTED] :: [EMAIL PROTECTED] :: http://www.nkuitse.com/ -- Paul Hoffman :: Taubman Medical Library :: Univ. of Michigan [EMAIL PROTECTED] :: [EMAIL PROTECTED] :: http://www.nkuitse.com/
Re: Adding libraries to Perl on Mac OS X
On Thursday, September 25, 2003, at 09:10 AM, Kevin Barry wrote: I'm have trouble adding perl libraries to my OS X machine. I've installed the developer tools and the gcc updater from August but when running the command install bundle::CPAN I get make errors. Warning: prerequisite Test::more failed to load: Can't locate Test/More.pm in @INC An r command to CPAN shows Test and Test::Harness as the only Test entries. Try 'install Test::More'. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
re: psync trouble
I'm getting close. psync doesn't seem to set file permissions. It sets directory permissions, sort of. I'm looking at the browser Camino. My source file /Camino.app/Contents/MacOS/Camino is set to 771. When psync copies it, the target /Camino.app/Contents/MacOS/Camino is set to 644. When I manually set it executable, the app launches fine. Problem solved by hand. Shouldn't psync set file permissions as well? If not how can I modify it to do so? Also, my psync output shows: 00776,admin,admin /test2/Camino.app/Contents/Resources but the directory looks to be 755: drwxr-xr-x 72 root admin 2448 Sep 25 10:13 Resources Sorry if this is obvious, but it has me searching. } All right, but apart from the sanitation, the medicine, } education, wine, public order, irrigation, roads, } the fresh-water system and public health, } what have the Romans ever done for us?
Re: File write/read problem
Well, I gave it a wirl and it works great. I love learning new things! Thanks so much for your help. Does anyone know of a good site for me to learn more about UNIX permissions? Thanks again, Mark - Original Message - From: Paul Hoffman [EMAIL PROTECTED] To: Mark Wheeler [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:08 AM Subject: Re: File write/read problem Mark, Leave the permissions on httpd.conf as they are, in case you're tempted to change them. :-) After you've read this message, I suggest you read up on UNIX permissions -- maybe someone else can recommend a good source of information. The key is that your CGI script runs as user www and group www. All the permissions have to take that into account. I'll describe one way to accomplish what (I think) you want; there may be others. What you need to do is change the owner and/or group of any directories to which your CGI script will be adding files, and of any *existing* files which your CGI script will be modifying. It sounds like you have the following setup: / Library/ WebServer/ CGI-Executables/ write.cgi file1.txt file2.txt ... First, it's not a good idea to create or modify files within the CGI-Executables (a.k.a. cgi-bin) directory, so I would *definitely* put any data files in a separate directory, called (say) CGI-Data: % cd /Library/WebServer % chmod o-w .# make sure permissions on /Library/WebServer are sane % sudo mkdir CGI-Data % ls -l drwxr-xr-x2 root admin 68 Sep 25 11:40 CGI-Data (I'll continue to edit the output of `ls -l' as I've done here.) If there are any existing files to move here, go ahead and move (or copy) them now: % sudo mv file1.txt file2.txt CGI-Data As it stands now, your CGI script won't be able to do anything in this directory or to its files -- you created it as root so, by default, root is its owner. I'm assuming that you want to be able to read and write things in this directory yourself, so what you can do is make yourself the owner and www the group. Let's say by some strange chance your user id is the same as mine, nkuitse: % sudo chown -R nkuitse:www CGI-Data % ls -l drwxr-xr-x 2 nkuitse www 68 Sep 25 12:05 CGI-Data OK, so now you (nkuitse) can do anything you want to do in this folder, and (because of the -R option, which means and do the same to the directory's contents, recursively) you can do anything to the files within it. But your CGI script still can't touch them, because the group permissions are still r-x. That's easy to fix: % chmod -R 775 CGI-Data % ls -l drwxrwxr-x 2 nkuitse www 68 Sep 25 12:05 CGI-Data Note two things: 1. sudo wasn't needed because now you're the owner, and you have write permission (unless you took away write permission from the files you moved, before you moved them) 2. chmod also has an -R option with the same effect as chown's Now all you have to do is modify your script so it writes to ../CGI-Data/file1.txt, etc. instead of just file1.txt, etc. Or you can use absolute paths like /Library/WebServer/CGI-Data/file1.txt if you prefer (this is less portable but that may not matter in your case). If you want to get fancy, you can set up individual subdirectories within CGI-Data, setting the permissions for one so your CGI script can only modify *existing* files, and setting them for the other so your CGI script can modify existing files *and* add files. HTH, Paul. On Thursday, September 25, 2003, at 10:08 AM, Mark Wheeler wrote: In just checked the httpd.conf file and, yes, the user/group is set to www/www. So I need to change it to what? Mark - Original Message - From: Paul Hoffman [EMAIL PROTECTED] To: John Delacour [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 5:23 AM Subject: Re: File write/read problem On Wednesday, September 24, 2003, at 10:44 PM, [EMAIL PROTECTED] wrote: OK, that makes perfect sense, but it is not working here. Here is a basic script which, when run, should create a new file called example.txt because it is not there when the open statement is used. #!/usr/bin/perl print Content-type: text/html\n\n; print Creating new file...; my $newtext = newtext from old; open (USER, example.txt); print USER $newtext; close USER; exit; As you've said, it should create the file in the same directory, in this case the cgi-bin, as the script (which is called write.cgi). I run the call the script from the browser and the script runs fine, except, no file is created. I added a || die ($!) at the file open call and add the CGI::CARP qw(fatalToBowser) at the top and get the following. Permission denied at /Library/WebServer/CGI-Executables/write.cgi
Re: Locale setting errors in Perl
On 25/9/03 22:19, Kevin Barry [EMAIL PROTECTED] wrote: I gave up trying to add modules to perl 5.6.0 and upgraded rather painlessly to 5.8.0. Now I get the error below when running any perl scripts: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = en_US [...] This is covered extensively in this list's archives. Try looking there. HTH, Regards, Phil. -- Playstation? Of course Perl runs on Playstation. -- Jarkko Hietaniemi
Re: Locale setting errors in Perl
At 17:19 -0400 9/25/03, Kevin Barry wrote: perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = en_US environment.plist lives in $HOME/.MacOSX/ (with a leading dot) It is read only at login time. And that means login to the OS neXt GUI and not login via Terminal or ssh. Just creating the .plist won't do anything until you logout and login again. And. . . I do wish Apple would fix that. A login should be a login to Darwin wherever it is performed. Your LC_ALL = (unset) line is suspect: Here is my file. ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyLANG/key stringus_ENG/string keyLC_ALL/key stringC/string keyPATH/key string/Users/doug/bin:/opt/bin/perl/bin:/bin:/sbin:/usr/bin:/usr/sbin:/Developer/Tools/string keyRCCOUNT/key string0/string keySHELLOG/key string/Users/doug/logs/shel_log/string keySERVER_NAME/key stringEarth/string /dict /plist -- -- There are 10 kinds of people: those who understand binary, and those who don't --
upgrading to 5.8.1
I suppose most of you know that perl-5.8.1 is now available ... http://www.perl.com/CPAN/src/perl-5.8.1.tar.gz I already have 5.8.0 installed using ... ./Configure -de -Dprefix=/usr/local/perl-5.8.0 ... and have a LOT of CPAN extras installed there as well. Is there an easy way to get install the new version in /usr/local/perl-5.8.1 and have it use all of my existing CPAN modules without reinstalling all of them? I tried doing ... sudo cp -pR /usr/local/perl-5.8.0 /usr/local/perl-5.8.1 ... before doing the 'make install' thinking it would do an upgrade, leaving the extra stuff alone, but it looks like it puts everything in 5.8.1 sub-directories and doesn't include the 5.8.0 sub-directories in @INC. -- 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
