 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / Perl / General Perl Topics / July 2009Best way to do server side tasks with new ISP
This is my first post here and I have never used Perl, so please bear with me. I am mostly a hardware guy but I have done a lot of programming since the punchcard days of the IBM 7094 in 1967, and MSDOS and Windows apps using BASIC, Pascal, C, and assembly, and embedded Z80 and PIC projects using assembly and C. More recently I have done some scripting in JavaScript and VB, and I have done some simple HTML for my website. I have been with the same dialup ISP, smart.net, since 1996, and I have been happy enough with the default performance and tools I have used, particularly a hit counter and the ability to view a directory that does not have an index.htm. But now I have switched to Verizon FIOS, and their 10M of web space has a broken web counter tool, and viewing of the files in a directory is forbidden. Also it seems that they do not allow a CGI-BIN for their residential service. So I am looking elsewhere for a website host. I could stay with Smart.net but their web space seems rather expensive. The domain registrar I use, MyDomain.com, has 10G webspace for about $6/month, and they say they have a full line of tools like a hit counter and they allow CGI-BIN, but they have permanantly disabled directory listing of files. It seems that JavaScript does not provide access to server-side file directories, and on one forum it was advised to look at http://us.php.net/manual/en/function.opendir.php. It looks like PHP is composed of elements of C, Java, and Perl. So I decided to look at Perl, and I have scanned much of the FAQ. It is rather overwhelming to analyze and compare the features of so many similar languages and attempt to become proficient in one or more, especially when I only need to accomplish a few rather simple things that have probably been done many times before. I plan to use Borland Delphi for all my local applications, and perhaps use JScript or VBScript with the WSH for simple local tasks. I also need to use JavaScript for programming PDF documents using Nitro Pro or Adobe Pro. And of course some applications such as Access require VBA. And I have also written some more complex apps in Delphi that use the automation interface to utilize methods, properties, and events of objects in other programs. Thus I am just trying to determine if I should attempt to use Perl, or perhaps PHP or some other language, to do what I want to do. Mostly, I would like to make a simple index.htm that can display a list of files in its directory so that users can simply click on any one for download. Mostly these will be JPG or TXT, but possibly also XLS, DOC, ZIP, or other common types. And I would also like to be able to implement a simple form that would have its results emailed to me, which of course is a common task, but I assume I would need a CGI application to do that. Thanks for any advice you may be able to provide. Paul E. Schoen www.pstech-inc.com > This is my first post here and I have never used Perl, so please bear with > me. I am mostly a hardware guy but I have done a lot of programming since [quoted text clipped - 7 lines] > particularly a hit counter and the ability to view a directory that does > not have an index.htm. [...] > but their web space seems rather expensive. The domain registrar I use, > MyDomain.com, has 10G webspace for about $6/month, and they say they have a [quoted text clipped - 3 lines] > It seems that JavaScript does not provide access to server-side file > directories, This is correct for JavaScript running in the browser (some web servers offer server side JavaScript - this has of course access to server-side resources, but not to browser resources). > and on one forum it was advised to look at > http://us.php.net/manual/en/function.opendir.php. It looks like PHP is > composed of elements of C, Java, and Perl. And Perl is composed of elements of C, awk, and sh (with a little bit of OOP and functional programming thrown into the mix). > So I decided to look at Perl, > and I have scanned much of the FAQ. It is rather overwhelming to analyze > and compare the features of so many similar languages and attempt to become > proficient in one or more, especially when I only need to accomplish a few > rather simple things that have probably been done many times before. [...] > Thus I am just trying to determine if I should attempt to use Perl, or > perhaps PHP or some other language, to do what I want to do. You could try to solve your problem in Perl, PHP, and a few other languages and see which one you like best. Here is a Perl solution which assumes that you can put Perl CGI programs directly into "normal" directories and aren't constrained to using cgi-bin: #!/usr/bin/perl use warnings; use strict; use CGI; my $cgi = CGI->new(); print "Content-Type: text/html; charset='UTF-8'\n"; print "\n"; print "<title>Directory listing of ", $cgi->escapeHTML($cgi->self_url), "</title>\n"; print "<ul>\n"; opendir(my $dh, "."); for (readdir($dh)) { print "<li><a href='", $cgi->escapeHTML($_), "'>", $cgi->escapeHTML($_), "</a></li>\n"; } print "</ul>\n"; __END__ Making the output more beautiful, adding metadata (size, modified date, etc.) and other embellishments are left as an exercise to the reader ;-). hp [snip] > Making the output more beautiful, adding metadata (size, modified date, > etc.) and other embellishments are left as an exercise to the reader > ;-). Thanks for the response. That code looks rather intimidating, compared to JavaScript. But at least it's a start, and perhaps I can get used to the syntax and make sense of it. Paul >That code looks rather intimidating, compared to >JavaScript. Well, what do you expect? The one is a simple DHTLM scripting language, the other is a fully-featured general purpose programming langauge. jue >>That code looks rather intimidating, compared to >>JavaScript. > > Well, what do you expect? The one is a simple DHTLM scripting language, > the other is a fully-featured general purpose programming langauge. Well, I am used to C and Pascal (Delphi), and a little bit of Visual Basic. I can do just about anything I need on my local machine with those languages. Then I tried some JavaScript and VBScript using the WSH for some simple file manipulation scripts, and found some limitations. I also used some JavaScript in a PDF, and ran into a few more limitations. But I am coming to understand the issues of security when one includes code (script) in an HTML document that is downloaded on someone else's machine. And another level of security when dealing with server-side CGI where even reading a directory or doing some simple file I/O can be dangerous. It's already a big leap from embedded assembly and C routines where all of the hardware and software are visible and under control of the designer, to applications that run in the context of an OS on a local machine, and then finally to an instruction set that works in the context of a web page in someone's browser, or a CGI program that accesses files and resources on a server. But mostly I can't understand why well-known languages such as C and Pascal, or even VB and .NET, are not used for CGI apps (although maybe they are), and instead require rather arcane-seeming code such as Perl and PHP. I will need to look into the language a bit more before I can really make a judgment as to its suitability for my purposes. For now, though, it just seems confusing. Paul >>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: PES> But mostly I can't understand why well-known languages such as C PES> and Pascal, or even VB and .NET, are not used for CGI apps PES> (although maybe they are), and instead require rather PES> arcane-seeming code such as Perl and PHP. I will need to look PES> into the language a bit more before I can really make a judgment PES> as to its suitability for my purposes. For now, though, it just PES> seems confusing. then you have never tried to do major text munging in c with all of its problems of memory management, poor string handling, etc. this is true for most compiled languages. perl was the best dynamic language when cgi came forth and became the defacto language of the web in those days. its ease of handling strings and memory made it popular with cgi and many other application areas. and thinking today that perl is still mostly used in cgi is way off base as it is used in many more areas and with major amounts of code (see cpan). and calling pascal well known today is just being silly. cobol is more well known and is still being coded. uri  SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Free Perl Training --- http://perlhunter.com/college.html --------- --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- > >>That code looks rather intimidating, compared to > >>JavaScript. [quoted text clipped - 28 lines] > > Paul C and Pascal can be used as CGI applications. But Perl and PHP applications can be run within the context of the web server, thereby scaling a whole lot better (e.g. each connection is still running inside the web server's process space rather than as a separate CGI process). Add access to MySQL and you have a full-service application platform. Just as C and Pascal had their day, there are other web-technologies attempting to replace Perl and PHP. Most web hosting companies offer Perl, PHP, and MySQL. Good luck finding Cold Fusion. Or open your wallet _yearly_ for Microsoft-based development environments. In this area, the standard development cycle of edit, compile/build, test is shortened by removing the compile/build phase. I guess it's time you decide if you want to do web development or continue doing your C and Pascal programs on DOS. I've been programming for 30+ years. I learned new languages when I needed to. Fortran, PDP-11, DEC-10, or VAX assembly couldn't do it all as it turns out. Just remember that the penalty for complaining is that you'll live longer (and continue using Pascal). At this rate, you'll outlive a lot of us. And you'll still be complaining about C and Pascal. SignatureDeeDee, don't press that button! DeeDee! NO! Dee... [I filter all Goggle Groups posts, so any reply may be automatically by ignored] > C and Pascal can be used as CGI applications. But Perl and PHP > applications can be run within the context of the web server, thereby [quoted text clipped - 3 lines] > > ... Maybe it's time to slow down a bit. The OP wants to be able to list one or more directories and a hit counter and a form-to-mail app. Directory listing is a web server thing in the first place. Assuming Apache, an .htaccess file with this content: Options +Indexes might do. If not, it ought to be possible to ask the web hosting provider to allow directory listing for a specific account, or for one or more specified directories. As regards hit counters and form-to-mail scripts, there are numerous of them out there that may or may not fit the OP's needs. In any case, I can't see anything wrong with using C for those apps instead of learning a new language. (The latter presupposes that the hosting provider allows compiling C programs.) Scalability, mod_perl and stuff seems not to be a major concern. SignatureGunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl > Directory listing is a web server thing in the first place. Assuming > Apache, an .htaccess file with this content: [quoted text clipped - 4 lines] > provider to allow directory listing for a specific account, or for one > or more specified directories. The OP already wrote that he asked them and that it is *not* possible to turn on directory listings and that they won't make an exception for him. hp >> Directory listing is a web server thing in the first place. Assuming >> Apache, an .htaccess file with this content: [quoted text clipped - 8 lines] > turn on directory listings and that they won't make an exception for > him. Even if that may be the case, it's not what he wrote. He said with respect to his current provider that "viewing of the files in a directory is forbidden", and that's what Apache tells you if directory listing is not enabled. SignatureGunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl >> The OP already wrote that he asked them and that it is *not* possible to >> turn on directory listings and that they won't make an exception for [quoted text clipped - 4 lines] > directory is forbidden", and that's what Apache tells you if directory > listing is not enabled. To quote from the first posting in this thread: | they say they have a full line of tools like a hit counter and they | allow CGI-BIN, but they have permanantly disabled directory listing of | files. hp >>> The OP already wrote that he asked them and that it is *not* possible >>> to [quoted text clipped - 11 lines] > | allow CGI-BIN, but they have permanantly disabled directory listing of > | files. Actually my current dialup ISP allows CGI and shows a directory when there is no index. But my new high speed ISP, verizon.net, apparently does not allow either, and their hit counter is broken. I get 10 M free, but I would like a little more. So I am really just shopping for webspace, and perhaps there are providers that will give me what I want for a reasonable amount, like $5/mo for 100 M or so. Thanks for the interesting discussion. Paul >>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: PES> Actually my current dialup ISP allows CGI and shows a directory PES> when there is no index. But my new high speed ISP, verizon.net, PES> apparently does not allow either, and their hit counter is PES> broken. I get 10 M free, but I would like a little more. So I am PES> really just shopping for webspace, and perhaps there are PES> providers that will give me what I want for a reasonable amount, PES> like $5/mo for 100 M or so. jeez, do you know how many web hosters there are out there? and that you can get decent deals for $5 or more a month? using your isp for a web host is usually a poor idea and even worse using them for the email domain. since you seem to have your own domain why don't you move it to a hoster that has what you want. most have large checklists of features for each plan they offer so it would be easy to find one that matches your needs. uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Free Perl Training --- http://perlhunter.com/college.html --------- --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- >>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes: MV> C and Pascal can be used as CGI applications. But Perl and PHP MV> applications can be run within the context of the web server, MV> thereby scaling a whole lot better (e.g. each connection is MV> still running inside the web server's process space rather than MV> as a separate CGI process). Add access to MySQL and you have a MV> full-service application platform. Er, C can be used within the context of the web server as well, and the last time I looked, there were C libraries for MySQL. Charlton SignatureCharlton Wilbur cwilbur@chromatico.net >>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: PES> But mostly I can't understand why well-known languages such as PES> C and Pascal, or even VB and .NET, are not used for CGI apps PES> (although maybe they are), and instead require rather PES> arcane-seeming code such as Perl and PHP. Here's an exercise that should illuminate things. If you solve this in idiomatic C and in idiomatic Perl, you'll start to see the advantage of Perl. Given the following line: foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true Produce the following output: * An alphabetically sorted list of the values assigned to each variable * The count of values assigned to each variable * The result of foo * 27 + 3 You can do this in about 20 lines of Perl, using several builtin functions. C operates at a much lower level, so instead of using Perl builtins, you have to write your own parser (instead of split), you have to worry about your data structures (instead of using a hash), you have to handle memory allocation manually (instead of just letting things go out of scope), you have to manually convert the value of foo to a number (instead of just treating it as a number and letting Perl do it for you). Now, to be sure, you can write a nice big C library to handle this for you. But when you're done, you'll have a one-off library that hasn't been extensively tested, and it will really just be a poor reimplementation of Perl -- which has been extensively tested for the past two decades. (And C *is* used for CGI. At a PPOE, one of my coworkers, who had moved from the embedded systems world to the web world, had written a number of CGI programs in C. They were a nightmare to deal with, because somewhere along the way -- this shop did not really believe in version control, and backups were a polite fiction -- the source code had been lost. Given the way his PHP code looked, though, I think that happy accident saved me some sanity points.) Charlton SignatureCharlton Wilbur cwilbur@chromatico.net > Given the following line: > [quoted text clipped - 5 lines] > * The count of values assigned to each variable > * The result of foo * 27 + 3 perl -wle ' my $line = "foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true"; my %par; push @{ $par{$1} }, $2 while $line =~ /([^=;]+)=([^;]+)/g; print for sort map @$_, values %par; print "-"x20; print for map scalar(@$_), values %par; print "-"x20; print $par{foo}[0] * 27 + 3; ' 1 b c c seven true yes -------------------- 1 3 1 1 1 -------------------- 30 SignatureRuud >>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes: R> Charlton Wilbur wrote: >> [problem specification, with instructions to try solving it in C >> and in Perl] R> [code to solve the problem] Well, yes, it isn't a particularly difficult problem, either in Perl or in C. The point is that it's a couple dozen lines of Perl at most, and probably closer to a couple hundred lines of C. Charlton SignatureCharlton Wilbur cwilbur@chromatico.net >>>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes: > > R> Charlton Wilbur wrote: > > >> [problem specification, with instructions to try solving it in C Given the following line: foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true Produce the following output: * An alphabetically sorted list of the values assigned to each variable * The count of values assigned to each variable * The result of foo * 27 + 3 > >> and in Perl] > [quoted text clipped - 5 lines] > >Charlton In no way, shape or form, is this a problem specification, nor anything of any use to anything or anybody, et all. You can't parse c/c++ with this simplistic approach. You can't get from HERE -->"foo=1;" to HERE --> "bar=yes;". You can't even get to HERE -->"foo=1;" Alpha sorted list of "values" assigned to each variable? Whats that tell ya? Count of values, here I assume you are adressing re-assignment, as if scope is not an issue. Finally, the result of foo's multiplicity. Are you desperately trying to be funny? -sln > In no way, shape or form, is this a problem specification, nor anything > of [quoted text clipped - 11 lines] > > Are you desperately trying to be funny? Yes, I was very confused about what the point was. I have no idea why the following line would ever need to be parsed in C, or in any other language: foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true Perhaps in a loosely typed language, "foo" would be assumed to be numeric, and probably integer. "bar" might be assumed to be Boolean, although in "C" that is really just an integer where "yes" would need to be predefined as non-zero. "baz" would be undefined unless "b" and "c" were previously defined. Same with "quux", where "seven" also needs to be defined, and then it is assigned to nothing, which would be an error unless it was specifically assigned to NULL or nil. And finally "submit" may be predefined as a Boolean, and true must also have been defined. I assume the given line is supposed to be a script which is to be interpreted and then some operations are supposed to be done on that process. Maybe in Perl and CGI there are reasons to do something like this, but it has just further complicated my understanding and avoidance of the language. And the point of using fewer lines to accomplish the same thing is not very beneficial if the code is difficult to understand. Delphi (Pascal) does tend to be rather verbose, and I wish there were constructs like {} rather than "Begin" and "End", but well-written code with liberal use of indentation and whitespace make it easy to understand and maintain. "C" has some operators that make for more compact code, but IMHO at the cost of readability. Then Perl seems to be at another level of brevity that reminds me of command line switches as used in MSDOS and even CP/M utilities like the line editor "ed". Paul >>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: PES> Yes, I was very confused about what the point was. I have no PES> idea why the following line would ever need to be parsed in C, PES> or in any other language: PES> foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true Consider a list of CGI form parameters in a GET query string. Charlton SignatureCharlton Wilbur cwilbur@chromatico.net >>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: > [quoted text clipped - 5 lines] > > Consider a list of CGI form parameters in a GET query string. Well, I had to look up what a GET query string was. I found a reasonable explanation at: http://www.antipope.org/charlie/attic/webbook/ch5perl/perl7.html Then I searched for what CGI form parameters were. I found: http://www.perlmeme.org/tutorials/cgi_form.html Now I am somewhat at a loss as to what created the GET query string in the first place, and I also see that it seems to use semicolons instead of the ampersands that are specified in the explanation. But my understanding is that a query string is usually generated as a result of items a user may have entered or selected in a blank form, and these items are then interpreted and converted to HTML so that a new document will be created according to the request of the user. So, AIUI, the CGI script only needs to parse the query string and then create a new HTML according to the parameters which were generated by the original form, and the script is written specifically for that form, so it already knows what the variables are, and what the values mean. So the string could be formatted in any way that the script could understand, and convert back to appropriate HTML. I'm also not quite sure why the query string needs to be part of the URL, although I can see that it identifies how the CGI script should format the special version of the form as desired by the user. Thus the original URL is just the blank form and the URL with the query is the modified version as created by the CGI script. I take it that this exists as a temporary file on the server which is then read by the browser? There is probably a very basic level of understanding that I just do not quite grasp. Paul >>>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: >> [quoted text clipped - 15 lines] > Now I am somewhat at a loss as to what created the GET query string in the > first place, Err, that would be a piece of technology often called a "web browser". > and I also see that it seems to use semicolons instead of the > ampersands that are specified in the explanation. An "explanation" is not "the standard". The Standard allows either character. > But my understanding is > that a query string is usually generated by a browser > as a result of items a user may > have entered or selected in a blank form, and these items are then > interpreted and converted to HTML by a "CGI program" This CGI program (in Perl in this case) must then decode the query string so that it can then generate the response. > I'm also not quite sure why the query string needs to be part of the URL, That is what The Standard says is supposed to happen for an HTTP GET request. For an HTTP POST request, the parameters are not in the URL, they are on STDIN. > There is probably a very basic level of understanding that I just do not > quite grasp. Indeed. You seem to not have a grasp of the rudiments of how the WWW (ie. HTTP requests and responses) operates. How it operates is independent of the language you choose to implement the parts necessary, and hence is not on-topic in a programming language newsgroup. Have you tried searching the Perl FAQ for info about CGI and HTML stuff: perldoc -q CGI How can I make my CGI script more efficient? Where can I learn about CGI or Web programming in Perl? What is the correct form of response from a CGI script? My CGI script runs from the command line but not the browser. (500 Server Error) How can I get better error messages from a CGI program? How do I make sure users can't enter values into a form that cause my CGI script to do bad things? How do I decode a CGI form? perldoc -q HTML How do I remove HTML from a string? How do I make a pop-up menu in HTML? How do I fetch an HTML file? How do I automate an HTML form submission? SignatureTad McClellan email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/" >>>>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: [snip] >> There is probably a very basic level of understanding that I just do not >> quite grasp. [quoted text clipped - 7 lines] >implement the parts necessary, and hence is not on-topic in >a programming language newsgroup. Now about ON-TOPIC, I wouldn't go that far Tad. If you take away applications, programming language newsgroups wouldn't exist. Larry would be the only poster here, questions and answers. -sln >>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: PES> There is probably a very basic level of understanding that I PES> just do not quite grasp. Yes, I'd say that's a very accurate statement. Charlton SignatureCharlton Wilbur cwilbur@chromatico.net >>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes: >Yes, I'd say that's a very accurate statement. > >Charlton I'm not sure you are qualified to determine accuracy are you fella? -sln >> In no way, shape or form, is this a problem specification, nor anything >> of >> any use to anything or anybody, et all. [snip] >Yes, I was very confused about what the point was. I have no idea why the >following line would ever need to be parsed in C, or in any other language: > > foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true [snip] >And the point of using fewer lines to accomplish the same thing is not very >beneficial if the code is difficult to understand. Delphi (Pascal) does [quoted text clipped - 7 lines] > >Paul Ah CP/M, z80(a), Zilog. My first real computer TimexSinclair Z80. Assembly, my first language. Z80a decompiler, my first program. In all fairness, I only read the last few posts starting with Dr. Ruud's apparent solution to what appeared (to him I think) to be a problem statement by Wilbur guy. Well, in all fairness to me, as threads fracture, so they become fractured. -sln >>>>> "sln" == sln <sln@netherlands.com> writes: >> Given the following line: >> >> foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true >> >> Produce the following output: >> >> * An alphabetically sorted list of the values assigned >> to each variable >> * The count of values assigned to each variable >> * The result of foo * 27 + 3 sln> In no way, shape or form, is this a problem specification, nor sln> anything of any use to anything or anybody, et all. On the contrary, if you were half the programmer you claim to be, you would recognize the rudimentary elements of CGI query string parsing. sln> You can't parse c/c++ with this simplistic approach. You can't sln> get from HERE -->"foo=1;" to HERE --> "bar=yes;". You can't sln> even get to HERE -->"foo=1;" Er, I'm not *trying* to parse C or C++, and I can, actually, parse the string as specified in the problem. sln> Alpha sorted list of "values" assigned to each variable? Whats sln> that tell ya? Count of values, here I assume you are adressing sln> re-assignment, as if scope is not an issue. Finally, the sln> result of foo's multiplicity. The point of the example, as noted above, was to produce an example problem that included the more basic elements of CGI processing, and in particular those that would demonstrate the annoyances with using C to write CGI-handling scripts. The original querent asked why Perl was used in preference to C for early web programming, and I thought a concrete example would be more useful than a history lesson. sln> Are you desperately trying to be funny? No. Are you desperately trying to be an idiot? Or are you just soused again? Charlton SignatureCharlton Wilbur cwilbur@chromatico.net >>>That code looks rather intimidating, compared to >>>JavaScript. [quoted text clipped - 5 lines] > I can do just about anything I need on my local machine with those > languages. [...] > But mostly I can't understand why well-known languages such as C and > Pascal, or even VB and .NET, are not used for CGI apps (although maybe > they are), They are. I wrote some web applications in C myself. But that was for an embedded system where the whole system (kernel, web server, application, and the data it processed) had to fit into a few MB of flash. It would have been quite a lot faster to develop the thing in Perl, but there simply wasn't space for a perl interpreter on the system (and using a bigger flash would have cost a lot more than my few hundred hours of work). > and instead require rather arcane-seeming code such as Perl > and PHP. Mass hosters can only offer a few technologies, and they will offer what their customers demand. Theses days this is usually PHP, plus a little bit of Perl, Python and Ruby, at least on Linux hosts. On Windows hosts, they may also offer VB and .NET, but I'm not a Windows guy so I wouldn't know that. If you want to write your web apps in C, it's probably best if you get a virtual host (I've seen some offers for less than 10€/month). Of course then you wouldn't need to write a CGI app just to print a directory listing because you can just configure your web server. hp >>That code looks rather intimidating, compared to >>JavaScript. How is that code "intimidating"? It's just a bunch of print statements and a simple loop. Assuming you had access to a directory, how would that code be simpler in JavaScript? > Well, what do you expect? The one is a simple DHTLM scripting language, > the other is a fully-featured general purpose programming langauge. JavaScript is a fully-featured general purpose programming language. In fact, if you look at the standard, you won't find HTML mentioned at all, except maybe in the preface. The DOM tree is just a data structure provided by the environment, not something built into the language. hp >>>That code looks rather intimidating, compared to >>>JavaScript. > > How is that code "intimidating"? It's just a bunch of print statements > and a simple loop. Well, it's probably just about learning the syntax: my $cgi = CGI->new(); // I don't understand what this does, except possibly assign string $cgi to something opendir(my $dh, "."); // I assume $dh is a string containing the directory in text form for (readdir($dh)) { // So this apparently reads the string one line at a time print "<li><a href='", $cgi->escapeHTML($_), "'>", $cgi->escapeHTML($_), "</a></li>\n"; // I know this must create HTML code for hyperlinks to the directory items The single and double quotes and various other characters and symbols probably make perfect sense to a Perl programmer, but they seem difficult to read and understand. > Assuming you had access to a directory, how would that code be simpler > in JavaScript? I'm not very fluent in JavaScript, but if I had access to an MSDOS command shell I would just execute a dir > dirfile.txt and then I would just parse the filenames and add appropriate HTML to prepend the URL of the directory to make them hyperlinks. >> Well, what do you expect? The one is a simple DHTLM scripting language, >> the other is a fully-featured general purpose programming langauge. [quoted text clipped - 3 lines] > except maybe in the preface. The DOM tree is just a data structure > provided by the environment, not something built into the language. I found JavaScript very limited when used in the context of the Windows Script Host, as it is designed to run in the context of a browser and an HTML document. It does have some file manipulation capability if you use an ActiveX FileSystemObject, where you can create directories and text files which can be written and read, and files can be copied from one place to another. But a local machine is a much different environment than a web server! Thanks for your patience in helping me understand more about various languages and their appropriateness to different environments. I don't think I want to learn Perl for the limited use I will probably have for it. I can see where it is a very powerful tool for text manipulation and negotiating the environment of the web server and user interaction with an HTML document, and gathering information. But it seems to be difficult to follow because of its shorthand notation for complex tasks. Paul Quoth "Paul E. Schoen" <paul@peschoen.com>: > Well, it's probably just about learning the syntax: > > my $cgi = CGI->new(); // I don't understand what this does, except > possibly assign string $cgi to something $cgi is a variable. Scalar (single-valued) variables in Perl always begin with a '$'. 'my' declares a new lexically-scoped variable. 'CGI->new()' is a method call on the class 'CGI': '->' is the Perl equivalent of '.' in JavaScript. A rough translation to JS might be var cgi = CGI.new(); or var cgi = new CGI (); since JS has a special syntax for constructors (in Perl they are just ordinary calss method calls). This isn't strictly accurate since JS has weird scoping rules for 'var' variables. Oh, and comments in Perl begin with '#', not '//'. > opendir(my $dh, "."); // I assume $dh is a string containing the > directory in text form No, $dh holds a directory handle open on the directory. A dir handle is like a file handle, but, err, different. (I've never understood why this was a necessary distinction. The OS should just treat read(2) on a dir as getdents(2), and Perl should treat <$DH> and readdir($DH).) > for (readdir($dh)) { // So this apparently reads the string one line > at a time No, it reads all the entries from the dir handle into a list, then iterates over the list. This is not the best way to write this: a while loop while ($_ = readdir($dh)) { (with appropriate 'local $_', 'local *_' or 'my $_') will read the entries one at a time and process each antry as it is read. > print "<li><a href='", $cgi->escapeHTML($_), "'>", > $cgi->escapeHTML($_), [quoted text clipped - 4 lines] > probably make perfect sense to a Perl programmer, but they seem difficult > to read and understand. Really? The '$cgi->escapeHTML()' bits are just method calls on the $cgi object. $_ is a magic variable that is set by 'for' to the current item in its list (this is really the only bit that is non-obvious). The double-quotes understand \-escapes (just like in JS) and interpolate variables. 'print' is a builtin that joins all its arguments together and writes the result to the standard output. Equivalent JS might be print("<li><a href='", cgi.escapeHTML(it), "'>", cgi.escapeHTML(it), "</a></li>\n"); assuming a loop like var entries = readdir(dh); for (var i = 0; i < entries.length; i++) { var it = entries[i]; (Notice how Perl makes the rather common operation of 'iterate over all the entries in a list' much easier than JS does. JS 1.6 has entries.forEach(function { print(...) }); but that isn't exactly pretty.) > I'm not very fluent in JavaScript, but if I had access to an MSDOS command > shell I would just execute a [quoted text clipped - 3 lines] > and then I would just parse the filenames and add appropriate HTML to > prepend the URL of the directory to make them hyperlinks. You can do that in Perl, if you like. It's not really a good idea, especially since your webserver is probably Unix-based and doesn't have a 'dir' command, but it's perfectly possible. > Thanks for your patience in helping me understand more about various > languages and their appropriateness to different environments. I don't > think I want to learn Perl for the limited use I will probably have for it. Oh, right. You could have said that first... > I can see where it is a very powerful tool for text manipulation and > negotiating the environment of the web server and user interaction with an > HTML document, and gathering information. But it seems to be difficult to > follow because of its shorthand notation for complex tasks. Having simple notation for complex but common tasks actually makes programs *easier* to read. Ben > Quoth "Paul E. Schoen" <paul@peschoen.com>: > [quoted text clipped - 4 lines] > > but that isn't exactly pretty.) Erm. JavaScript 1.5 *does* have the equivalent construct: 'for (var in list)'. Mart Signature"We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source. >> Quoth "Paul E. Schoen" <paul@peschoen.com>: >> [quoted text clipped - 10 lines] > > 'for (var in list)'. But that iterates over the entire prototype chain: http://yuiblog.com/blog/2006/09/26/for-in-intrigue/ SignatureTad McClellan email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/" >>> Quoth "Paul E. Schoen" <paul@peschoen.com>: >>> [quoted text clipped - 14 lines] > > http://yuiblog.com/blog/2006/09/26/for-in-intrigue/ If you use an object to iterate over, yes. If you feed it an array, it works the same as Perl's foreach. Of course, since you can add properties to just about anything, you can never be sure if you're actually iterating over an array. Javascript is a bit quirky in that. But to me, it feels remarkably close to Perl, funnily enough. Mart Signature"We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source. Quoth Mart van de Wege <mvdwege@mail.com>: > >>> Quoth "Paul E. Schoen" <paul@peschoen.com>: > >>> [quoted text clipped - 17 lines] > If you use an object to iterate over, yes. If you feed it an array, it > works the same as Perl's foreach. Bzzzt! Wrong. Arrays are objects in JS, so anything added to Array.prototype or Object.prototype will show up in the Array's properties. > Of course, since you can add properties to just about anything, you can > never be sure if you're actually iterating over an array. ...quite. The lack of lists is one of the things I find most annoying about JS (well, that and refs, and the fact 'function' has such a long name). > Javascript is a bit quirky in that. But to me, it feels remarkably > close to Perl, funnily enough. It does, doesn't it? I think it's having both hashes and lexical closure that does it. Ben > Quoth Mart van de Wege <mvdwege@mail.com>: >> [quoted text clipped - 23 lines] > Array.prototype or Object.prototype will show up in the Array's > properties. Well yeah. It pays to read further than a single paragraph, doesn't it? >> Of course, since you can add properties to just about anything, you can >> never be sure if you're actually iterating over an array. <snip> >> Javascript is a bit quirky in that. But to me, it feels remarkably >> close to Perl, funnily enough. > > It does, doesn't it? I think it's having both hashes and lexical closure > that does it. For me, the fact that objects are merely hashes of properties felt very familiar. The canonical Perl object is conceptually not much different. Of course, as soon as you start using prototypical inheritance, Javascript shows its differences, but the starting point is remarkably similar. Mart Signature"We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source. >>>>That code looks rather intimidating, compared to >>>>JavaScript. [quoted text clipped - 6 lines] > my $cgi = CGI->new(); // I don't understand what this does, except > possibly assign string $cgi to something There is no string there. It is creating an object. Are you familiar with object oriented programming? > opendir(my $dh, "."); // I assume $dh is a string containing the > directory in text form The only string there is the one containing a dot. $dh is a dirhandle, it is not a string. Had you bothered to read the documentation for the function being used, that should have been fairly obvious: perldoc -f opendir opendir DIRHANDLE,EXPR > for (readdir($dh)) { // So this apparently reads the string one line > at a time Finally, a statement that _does_ have a string associated with it. Besides what you have in your (non-Perl) comment, it also assigns that string to the $_ variable. > print "<li><a href='", $cgi->escapeHTML($_), "'>", > $cgi->escapeHTML($_), > "</a></li>\n"; // I know this must create HTML code for > hyperlinks to the directory items Along with some method calls on the CGI object. > The single and double quotes and various other characters and symbols > probably make perfect sense to a Perl programmer, but they seem difficult > to read and understand. The funny characters in the Cyrillic alphabet probably make perfect sense to a Russian speaker, but they seem difficult to read and understand. Well duh, foreign languages seem, well, foreign (until you learn them). SignatureTad McClellan email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/" PES> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message PES> news:slrnh4kt61.mqq.hjp-usenet2@hrunkner.hjp.at... >> How is that code "intimidating"? It's just a bunch of print >> statements and a simple loop. PES> Well, it's probably just about learning the syntax: It *is* just about learning the syntax. Well, and the semantics. Perl is not Javascript, C, VB, or Pascal. You need to get your head around that concept first. You can use what you know of other languages to help you get a handle on Perl, but the sooner you accept Perl for what it is, and stop trying to understand it as if it were some other language with lots of errors, the sooner you'll start making progress. PES> The single and double quotes and various other characters and PES> symbols probably make perfect sense to a Perl programmer, but PES> they seem difficult to read and understand. Fortunately, there are plenty of resources to help you learn to read and understand them. All languages have learning curves. Why did you accept C and Pascal's, but balk at Perl's? Charlton SignatureCharlton Wilbur cwilbur@chromatico.net > PES> The single and double quotes and various other characters and > PES> symbols probably make perfect sense to a Perl programmer, but > PES> they seem difficult to read and understand. > >All languages have learning curves. Why did you accept C and Pascal's, >but balk at Perl's? Well, VB, Pascal, C, they are all the same anyway. Try Lisp, Prolog, and APL. After you got familiar with those Perl will feel like a vacation on a tropical island with a light breeze and a pina colada in your hands. jue > And I would also like to be able to implement a simple form that would have > its results emailed to me, which of course is a common task, but I assume I > would need a CGI application to do that. > > Thanks for any advice you may be able to provide. Please permit me to make a couple of late comments. I am a heavy user of Perl in my job, which is mostly slicing and dicing data. Perl is a special purpose tool which is exceptionally good at its intended purpose: string handling. As most web apps are applications of handling strings, Perl is exceptionally good at writing web apps. It's also very good at database and networking applications ... but don't think that Perl is a good general purpose language, because it wasn't designed to be. I'll be glad to share code with you privately if you will email me at / c c c 3 1 8 0 7 at y a h o o dot c o m/. About 90 percent of the code will be instantly recognizable to you as HTML, CSS, or JavaScript. The other ten percent will probably strike you as obfuscated and obscure Perl, but hey, Perl by nature is obfuscated and obscure, which is why it's good at what it does. CC |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.