Re: Problems with interchange
Hi Antonio, I've used Interchange on linux. Had a devil of a time getting it to work, but it is a really nice cart. Still haven't resolved an issue with Skipjack, though another config process would probably do it. Just no projects screaming for it right now... But after all the difficulty I had getting it to work on Red Hat, I wasn't very anxious about putting it on my OS X machines. On a side note, I don't think brusque treatment on the interchange list is exclusive to OS X users. I've seen one of the developers get pretty childish about a bug he denied existed. Well, the bug really was there and the list was sheer chaos for about a week. But it got better. I'd say it would be a possibility to get Interchange working on OS X if you were decent with debugging perl, and had plenty of time to weed through layers of less-than-current documentation and the occasional wounded ego. But like I said, it is a really good cart. Hope I didn't rain on any parades. Troy On Thursday, April 25, 2002, at 05:31 PM, Antonio Blanco wrote: Hi to everyone, Has anyone had any experience with interchange (interchange.redhat.com), it's a very interesting perl based GNU e-commerce server. I'm running it on macosx 10.1.3 with perl 5.6.1 apache 1.3.23 and mysql 3.23.47, the server is running fine but the administration part is not working, any help would be appreciated. Thanks in advance
Re: Problems with interchange
Hi to everyone, Has anyone had any experience with interchange (interchange.redhat.com), it's a very interesting perl based GNU e-commerce server. I'm running it on macosx 10.1.3 with perl 5.6.1 apache 1.3.23 and mysql 3.23.47, the server is running fine but the administration part is not working, any help would be appreciated. Thanks in advance Hi, my IC Shop and admin interface is working with the tip from the helpfull IC mail list: I always had a segment fault error message but after splitting the de_DE.cfg in to files everything is fine. I only have this snip from the original mail. - the perl dumped, when loading the UI - loading individual locale settings - the UI is loading, when i commented out the line in VendRoot/lib/UI/ui.cfg : include lib/UI/locales/*_*.cfg (after the CSS-stuff) - UI starts with the default locale setting english - after enabeling each locale-file separately from locales/*_*.cfg only the file ja_JP.cfg loads without crashing - unfortunately i don't know japanese ;-( - then i found that the ja_JP.cfg file has the smallest size - it seems that the file size is the cause for crashing - so i split the de_DE.cfg file in two files and load these two files in ui.cfg - IC with UI comes up with english and german lang. - maybe there are better workarounds... HTH Achim Hope this helps. Best regards Goetz Verdieck == [EMAIL PROTECTED]
Re: Problems with interchange
Hi, I found the mail in the archive: http://interchange.redhat.com/archive/interchange-users/2002/msg11261.html Best regards Goetz Verdieck == [EMAIL PROTECTED]
Re: MacOSX-File-0.50.tar.gz uploaded to CPAN
On Friday, April 26, 2002, at 06:28 , Vonleigh Simmons wrote: Hello, Hi there. Dan, you are the man for making psync. I just tried it to backup my main drive and it works exactly as advertised. One question though, how would I go about restoring a drive? Should I just boot from the copy and copy back to the main drive, or is there a niftier restore feature? (didn't quite understand the -r flag in the man pages). Suppose you've backed up your drive with something like; psync / /Volume/backup If you are booting from the same drive, you can intuitively psync /Volume/backup / # it won't mangle /Volue/backup like cp Or, if you are booting from the volume you just backed up, you can psync / /Volume/newdrive to do so. As for -r option, not all 'Volumes' can store all the necessary file metadata (such as Apple Share volumes; you'll lose file ownership) so when you use -r, an extra database is created and used when you restore. In any case, thanks a bunch for making psync, awesome job. I'm trying to figure out if maybe I could make a cocoa front end for it, so that it would backup on a repeating basis (user defined), plus being able to restore. I'd do a cron job for it, but maybe it would be better to get it out to the less unix-savvy user. For the time being I am too occupied with Perl 5.8 but when it settles I would like to work further on with MacOSX::File. Thanks for your input. FYI, MacOSX::File is now 0.64. Use the latest one. Dan the Man with Too Many Modules to Manage -- _ Dan Kogai __/ CEO, DAN co. ltd. /__ /-+-/ 2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ - __/ /Tel:+81 3-5665-6131 Fax:+81 3-5665-6132 GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc
APACHE, LIBAPREQ -- some errors
RE: instructions at http://www.apache.org/~joes/ I have had the following errors after installing the special Apache. dyld: /usr/sbin/httpd Undefined symbols: _ApacheCookie_as_string _ApacheCookie_attr _ApacheCookie_bake _ApacheCookie_expires _ApacheCookie_new _ApacheCookie_parse /usr/sbin/apachectl restart: httpd could not be started In a unrelated error, can anyone verify that the following error is an indication that another server is already running? [crit] (13)Permission denied: make_sock: could not bind to port 80 I presume that mac os x is launching apache at startup. Is it possible that I have 2 versions of apache installed? I presumed that installation of apache by myself would overwrite anything that came pre-installed on the computer, no? BTW, thanks for all who have been responding to my emails! It is great to have such wonderful support. Hopefully I will someday be able to return the favor. Thanks! ward
Help with Apache installation
I thought I would go back to installing everything. Last time, when I installed Apache, I had had problems with the following command: SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip Telling me that SSL_BASE is not understood. So I set it using % Setenv SSL_BASE /usr/local/src/openssl-0.9.6c/ % ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip % make % make test % make install I have maked openssl, mod_ssl, and mod_perl. When I try to configure Apache, I am still getting the 'SSL_BASE is not understood' error. I am using Apple's default shell. Any help is appreciated! Thanks, Ward -- Ward W. Vuillemot [EMAIL PROTECTED]
Re: CPAN shell error with DELETE key
Date: Wed, 24 Apr 2002 11:58:40 -0400 From: Bill -Sx- Jones [EMAIL PROTECTED] On 4/24/02 10:37 AM, Vuillemot Ward W. [EMAIL PROTECTED] wrote: Is it me, or is Apache/Perl poorly supported on Mac OS X? That is to say, Apple has done enough changes to UNIX to break a lot of things that should just plain work. One of the reasons I am/was excited by Mac OS X was its UNIX underpinnings. As a web developer, I thought I would finally be able UNIX, in general, doesn't just plain work. Never has for me - but maybe I am being too Think Skulled ??? Unix is NOT the same across platforms by any stretch of the imagination. It never was, and it never will be. If it was, it would be called WinTel. I normally work with Tru64 Unix on Alpha and with Alpha Linux, and I can say without qualms that the Open Source community simply does not support anything but Sparc or Intel. And it simply cannot deal with the idea of a 64bit clean environment. It takes exceptional work by a very small cadre of very dedicated people to provide all of the ports to all of the other platforms that exist. That any Open Source software exists at all for non-Sparc and non-Intel platforms is a minor miracle. I've used many, many different iterations of Unix in the past 20+ years and every one of them is different. There is nothing which can be described as should just plain work as soon as you leave the explicit relm of Unix branding, POSIX compliance and the like. Personally, I find far more broken and idiotic assumptions in every Linux implementation I've worked with than with OS X. Don't like Netinfo -- then stay away from Sun's YP. Miss /etc/passwd? Then don't contemplate C2 security. Hack scripts depend upon things that should just plain work, but for which there is no valid reason for them to work. OS X is incredibly secure. It is THE MOST OUT OF THE BOX, SECURE SHIPPING UNIX today -- bar none. I run Tru64 in C2 mode, but we have to build the system and sanitize it off-line before it is secure enough to plug into a remote network. The only open hole that OS X ships with is NFS. I can not say the same thing for HP-UX, AIX, Solaris, Tru64 or any version of Linux. Period. Yes, that means that some things don't just plain work. But it means that I can sleep much better at night. -- T.T.F.N. William H. Magill Senior Systems Administrator Information Services and Computing (ISC) Networking Telecommunications University of Pennsylvania [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.isc-net.upenn.edu/~magill/ [EMAIL PROTECTED]
Re: Controlling Apache
Ward W. Vuillemot wrote: So I know have mod_ssl, mod_perl, Perl 5.6.1 and Apache loaded on my machine. I then loaded the libapreq that is suggested for this type of configuration. I can Apache to launch with the default httpd.conf. However, when I add the following line to the end of the file I get errors. Below are the mods to httpd.conf and associated files. I have been using System Preferences to restart Apache. However, after doing a restart I cannot STOP Apache from this location!! Q: What is the best way to control Apache? The beauty of comman line control! Open a terminal... sudo apachectl stop You can also do a start, restart, configtest (great for checking the compile of the httpd.conf file) and more. Also, even though Apache is running when I try to connect at 127.0.0.1 I get nothing?!? Well, once again, command line can be your friend... The apache logs (access and error) are under /var/log/httpd/ From a Terminal window, type: tail -f /var/log/httpd/access_log Then try loading 127.0.0.1. See if it even sees the access request. Control-C will cancel the continuous tail. Try tailing the error_log in that same directory and see if an error occurs. I would even vi the error_log and see if anything complained while it tried to start. Also, make sure that apache is really running too, via a process list. My fav is: ps wax | grep http Hope that helps. -Alex
Re: Help with Apache installation
On 4/26/02 8:39 AM, Ward W. Vuillemot [EMAIL PROTECTED] claimed: I thought I would go back to installing everything. Last time, when I installed Apache, I had had problems with the following command: SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip Telling me that SSL_BASE is not understood. So I set it using % Setenv SSL_BASE /usr/local/src/openssl-0.9.6c/ % ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip % make % make test % make install Both of these should work -- I don't get it. Try switching to zsh and doing it again: % zsh % SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip etc. Good luck, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Clean install
All, I want to do a complete reinstall of Apache, mod_perl, mod_ssl, openSSL and perl. What files do I need to delete to get rid of all the associated files? It would seem that I might have problems with different versions of libapreq, and I figure the easiest solution at this point is the M$ solution. REINSTALL. :| Cheers, Ward -- Ward W. Vuillemot [EMAIL PROTECTED]
Re: Clean install
On Fri, 26 Apr 2002, Ward W. Vuillemot wrote: I want to do a complete reinstall of Apache, mod_perl, mod_ssl, openSSL and perl. What files do I need to delete to get rid of all the associated files? Have you considered leaving the defaults alone, and just disabling them while you go put your own stuff in /usr/local? This is roughly how things are usually done on other flavors of Unix, partly because it frees you from the vendor's whim: it would be frustrating to remove all this stuff, only to have Apple reinstall it when the next update comes out, no? Just install these things with /usr/local as the basedir and pretend that you don't even have the Apple supplied versions. -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc
strftime issues
Hi All,
In the process of installing Matt Seargent's Time::Piece module on my OS X
box (a forthcoming version should support OS X -- the one currently on the
CPAN does not), one of the tests failed. That test used the strftime system
function to format the date. It returned 'V' for the '%V' format, which,
according to the OS X strftime man page, is
%Vis replaced by the week number of the year (Monday as the first
day of the week) as a decimal number (01-53). If the week
containing January 1 has four or more days in the new year, then
it is week 1; otherwise it is week 53 of the previous year, and
the next week is week 1.
Since Time::Piece uses the OS's own strftime function for its work, it
seemed strange to me that one of the formatting characters documented on the
system just simply wouldn't work.
So I put together a quick test (using POSIX::strftime) of all the documented
OS X strftime formatting characters to see what would happen. It turns out
that 4 of the 37 formatting characters fail to do what they document. The
four are:
'%C' -- Should be '20', for the century, but is 'Fri Dec 14 17:57:37 2001'
instead. Was it changed to ctime format but not documented?
'%u' -- Should be day of week, 5 in the example. Turns up 'u' instead,
which is just strange.
'%V' -- Should be week of month, 50 in the example. Turns up 'V' instead,
which is just strange.
'%Z' -- Should be the time zone, 'PST', but turns up nothing ('') instead.
I enclose the script for your perusal.
So my question is, does anyone know why the OS X strftime function works
differently than it has been documented? Could it be that it has a bug or
two, or that Perl somehow doesn't bind properly (the latter makes no sense
to me).
FWIW, I tested this script on my i686 RedHat box, and all the tests passed
(excepting some difference necessitated by a different locale).
Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
strftimetest
Description: Binary data
Re: strftime issues
There is an existing bug report, at least about the %Z problem:
2861261 - Bug in Perl's POSIX library in OSX 10.1.2
I will attach your message about the other ones.
I stumbled on the %Z problem myself, and for my needs, have worked around
it by using Date::Format. But I seem to think that the problem is not the
system level strftime, since I vaguely remember writing a test C program,
and %Z worked there. My sense is that the POSIX interface to strftime is
somehow not working fully.
For those of you who have built other versions of Perl under Mac OS X and
run the tests, POSIX is one of the tests that fails, though not about
dates, but something else (which I'm not remembering right of the top of
my head). So I suspect there are problems with the POSIX module under Mac
OS X, but haven't had the time to further investigate.
--
Edward Moy
Apple Computer, Inc.
[EMAIL PROTECTED]
On Friday, April 26, 2002, at 11:47 AM, David Wheeler wrote:
In the process of installing Matt Seargent's Time::Piece module on my OS
X
box (a forthcoming version should support OS X -- the one currently on the
CPAN does not), one of the tests failed. That test used the strftime
system
function to format the date. It returned 'V' for the '%V' format, which,
according to the OS X strftime man page, is
%Vis replaced by the week number of the year (Monday as the first
day of the week) as a decimal number (01-53). If the week
containing January 1 has four or more days in the new year,
then
it is week 1; otherwise it is week 53 of the previous year, and
the next week is week 1.
Since Time::Piece uses the OS's own strftime function for its work, it
seemed strange to me that one of the formatting characters documented on
the
system just simply wouldn't work.
So I put together a quick test (using POSIX::strftime) of all the
documented
OS X strftime formatting characters to see what would happen. It turns out
that 4 of the 37 formatting characters fail to do what they document. The
four are:
'%C' -- Should be '20', for the century, but is 'Fri Dec 14 17:57:37
2001'
instead. Was it changed to ctime format but not documented?
'%u' -- Should be day of week, 5 in the example. Turns up 'u' instead,
which is just strange.
'%V' -- Should be week of month, 50 in the example. Turns up 'V'
instead,
which is just strange.
'%Z' -- Should be the time zone, 'PST', but turns up nothing ('')
instead.
I enclose the script for your perusal.
So my question is, does anyone know why the OS X strftime function works
differently than it has been documented? Could it be that it has a bug or
two, or that Perl somehow doesn't bind properly (the latter makes no sense
to me).
FWIW, I tested this script on my i686 RedHat box, and all the tests passed
(excepting some difference necessitated by a different locale).
Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: strftime issues
Thanks Edward. FWIW (and I should probably have mentioned this in my original post), I'm running OS X 10.1.4, and Perl 5.6.1, which I compiled myself. I don't remember POSIX tests failing, but that doesn't mean it didn't happen. It might make sense to write a comprehensive stftime test app in C to see how it differs from what my Perl script found. I would do it, but I'm JAPH. ;-) BTW, where can I check out the existing bug reports? Thanks, David On 4/26/02 12:10 PM, Edward Moy [EMAIL PROTECTED] claimed: There is an existing bug report, at least about the %Z problem: 2861261 - Bug in Perl's POSIX library in OSX 10.1.2 I will attach your message about the other ones. I stumbled on the %Z problem myself, and for my needs, have worked around it by using Date::Format. But I seem to think that the problem is not the system level strftime, since I vaguely remember writing a test C program, and %Z worked there. My sense is that the POSIX interface to strftime is somehow not working fully. For those of you who have built other versions of Perl under Mac OS X and run the tests, POSIX is one of the tests that fails, though not about dates, but something else (which I'm not remembering right of the top of my head). So I suspect there are problems with the POSIX module under Mac OS X, but haven't had the time to further investigate. -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: strftime issues
On Fri, 26 Apr 2002, David Wheeler wrote:
It might make sense to write a comprehensive stftime test app in C to see
how it differs from what my Perl script found. I would do it, but I'm JAPH.
;-)
On 4/26/02 12:10 PM, Edward Moy [EMAIL PROTECTED] claimed:
I stumbled on the %Z problem myself, and for my needs, have worked around
it by using Date::Format. But I seem to think that the problem is not the
system level strftime, since I vaguely remember writing a test C program,
and %Z worked there. My sense is that the POSIX interface to strftime is
somehow not working fully.
Here's a test program you can copy into a file named test.c and compile it
with cc -o test test.c. I've included my Solaris output below the
program, so you can compare.
#include sys/types.h
#include stdio.h
#include time.h
void main()
{
int strsize = 255;
time_t timeAsNumber;
struct tm *temp;
char str[256];
timeAsNumber = time(NULL);
temp = localtime( timeAsNumber);
strftime (str, strsize, a: %a, temp);
printf (%s\n, str);
strftime (str, strsize, A: %A, temp);
printf (%s\n, str);
strftime (str, strsize, b: %b, temp);
printf (%s\n, str);
strftime (str, strsize, B: %B, temp);
printf (%s\n, str);
strftime (str, strsize, c: %c, temp);
printf (%s\n, str);
strftime (str, strsize, C: %C, temp);
printf (%s\n, str);
strftime (str, strsize, d: %d, temp);
printf (%s\n, str);
strftime (str, strsize, D: %D, temp);
printf (%s\n, str);
strftime (str, strsize, e: %e, temp);
printf (%s\n, str);
strftime (str, strsize, G: %G, temp);
printf (%s\n, str);
strftime (str, strsize, h: %h, temp);
printf (%s\n, str);
strftime (str, strsize, H: %H, temp);
printf (%s\n, str);
strftime (str, strsize, I: %I, temp);
printf (%s\n, str);
strftime (str, strsize, j: %j, temp);
printf (%s\n, str);
strftime (str, strsize, k: %k, temp);
printf (%s\n, str);
strftime (str, strsize, l: %l, temp);
printf (%s\n, str);
strftime (str, strsize, m: %m, temp);
printf (%s\n, str);
strftime (str, strsize, M: %M, temp);
printf (%s\n, str);
strftime (str, strsize, n: %n, temp);
printf (%s\n, str);
strftime (str, strsize, p: %p, temp);
printf (%s\n, str);
strftime (str, strsize, r: %r, temp);
printf (%s\n, str);
strftime (str, strsize, R: %R, temp);
printf (%s\n, str);
strftime (str, strsize, S: %S, temp);
printf (%s\n, str);
strftime (str, strsize, t: %t(tab) T: %T, temp);
printf (%s\n, str);
strftime (str, strsize, u: %u, temp);
printf (%s\n, str);
strftime (str, strsize, U: %U, temp);
printf (%s\n, str);
strftime (str, strsize, V: %V, temp);
printf (%s\n, str);
strftime (str, strsize, w: %w, temp);
printf (%s\n, str);
strftime (str, strsize, W: %W, temp);
printf (%s\n, str);
strftime (str, strsize, x: %x, temp);
printf (%s\n, str);
strftime (str, strsize, X: %X, temp);
printf (%s\n, str);
strftime (str, strsize, y: %y, temp);
printf (%s\n, str);
strftime (str, strsize, Y: %Y, temp);
printf (%s\n, str);
strftime (str, strsize, Z: %Z, temp);
printf (%s\n, str);
printf (now I've said my a-b-c's...\n);
}
- End program -
- Begin output
a: Fri
A: Friday
b: Apr
B: April
c: Fri Apr 26 16:34:31 2002
C: Fri Apr 26 16:34:31 CDT 2002
d: 26
D: 04/26/02
e: 26
G: 2002
h: Apr
H: 16
I: 04
j: 116
k: 16
l: 4
m: 04
M: 34
n:
p: PM
r: 04:34:31 PM
R: 16:34
S: 31
t: (tab) T: 16:34:31
u: 5
U: 16
V: 17
w: 5
W: 16
x: 04/26/02
X: 16:34:31
y: 02
Y: 2002
Z: CDT
now I've said my a-b-c's...
- End output --
--
MattLangford
Re: strftime issues
On 4/26/02 2:39 PM, Matthew Langford [EMAIL PROTECTED] claimed: Here's a test program you can copy into a file named test.c and compile it with cc -o test test.c. I've included my Solaris output below the program, so you can compare. Cool! Here's what I got: - Begin output a: Fri A: Friday b: Apr B: April c: 04/26/02 14:46:38 C: Fri Apr 26 14:46:38 2002 d: 26 D: 04/26/02 e: 26 G: G h: Apr H: 14 I: 02 j: 116 k: 14 l: 2 m: 04 M: 46 n: p: PM r: 02:46:38 PM R: 14:46 S: 38 t: (tab) T: 14:46:38 u: u U: 16 V: V w: 5 W: 16 x: 04/26/02 X: 14:46:38 y: 02 Y: 2002 Z: PDT - End output -- From this I draw the following conclusions: 1. %Z is broken in Perl's POSIX strftime() function. 2. %C works differently thatn documented in the OS X strftime man page. Rather than printing the century number (20), it prints the ctime format. 3. %V and %u don't appear to be supported on OS X, despite what the strftime man page says. Thus, I would guess that just the documentation needs to be updated. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
puzzling results from missing she-bang
I performed a test, and was surprised by the results. Can anyone tell me why the result occurs? File: -rwxr-xr-x 1 mt staff 25 Apr 26 19:07 hw.pl contents: print Hello, World.\n; command ../hw.pl results: Hello, World. Note the missing she-bang line: #!/usr/bin/perl -w Note also that I didn't tell the shell how to execute the file. So the file is set to executable, but I thought it should error. Is that line not necessary on a Mac for some reason? How is this a Mac thing? It is not functional on other unix machines I have access to (and I tried various shells, including tcsh bash). I repeated the experiment with no .pl extension, that isn't it. I suspect that it is a shell issue of some kind. /Michael Turner
Re: puzzling results from missing she-bang
On Friday, April 26, 2002, at 07:21 PM, Michael Turner wrote:
Note the missing she-bang line: #!/usr/bin/perl -w Note also that I
didn't tell the shell how to execute the file. So the file is set to
executable, but I thought it should error. Is that line not necessary
on a Mac for some reason? How is this a Mac thing? It is not functional
on other unix machines I have access to (and I tried various shells,
including tcsh bash). I repeated the experiment with no .pl
extension, that isn't it.
I repeated your experiment, but with a .sh extension instead. It worked.
Then, I ran the script with sh test.sh - again, it worked.
Then, I tried another script:
print $ENV{'HOME'};
The output was this:
{HOME}
Aha! That's the output that one would expect if $ENV{'HOME'} were
evaluated in a shell script, rather than a Perl script.
It appears that the shell, when asked to run something that isn't a
binary and has no shebang, defaults to running it as a shell script. As
it happens, the output of your first test script is the same, regardless
of whether it's run by the shell or by Perl.
sherm--
Never put off until tomorrow what you can do today. There might be a law
against it by that time.
Re: puzzling results from missing she-bang
On Friday, April 26, 2002, at 07:41 PM, Sherm Pendley wrote: It appears that the shell, when asked to run something D'oh! s/shell/kernel/; sherm--
Re: Help with Apache installation
At 9:31 AM -0700 4/26/2002, David Wheeler wrote: On 4/26/02 8:39 AM, Ward W. Vuillemot [EMAIL PROTECTED] claimed: I thought I would go back to installing everything. Last time, when I installed Apache, I had had problems with the following command: SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip Telling me that SSL_BASE is not understood. So I set it using % Setenv SSL_BASE /usr/local/src/openssl-0.9.6c/ % ./configure \ [...] Both of these should work -- I don't get it. Try switching to zsh and doing it again: % zsh % SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip etc. If you prefer to use the default tcsh, this will work: % env SSL_BASE=/usr/local/src/openssl-0.9.6c/ \ ./configure \ --with-layout=Apache \ --enable-module=ssl \ --enable-module=rewrite \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl \ --without-execstrip Note that --with-layout=Apache will install in /usr/local as noted elsewhere in this thread. Leaving it off or using --with-layout=Darwin will install it over Apple's defaults. -Charles Albrecht [EMAIL PROTECTED]
