«

On Saturday, December 29, 2012 11:55:31 AM UTC-5, E.D.G. wrote:
> Question: What type permissions should be assigned to different types of
> CGI files and directories?


Assuming that you use Apache and mod_perl, you can put all your CGI files into (sub)directory and configure Apache to send all files in that (sub)directory to the running Perl process. As long as your scripts run withut errors, you won't have a problem as far as outside visibility. Once upon a time, I had a problem with the browser rendering Perl scripts as text, but thatmay have been because I either named the files with an extension other than'.cgi' or because I didn't have Apache configured properly, I really don'tremember, but that's something that you will test and if it happens to youit can be corrected.

This isn't especially a matter of file permissions. If Apache can't read your file, the you will get a permissions denied error and Apache won't serveup your CGI content.

When I say 'outside visibility' I mean as an HTTP request via a web client,some browser, over port 80. Obviously, anyone with console access to your server would be able to see all the files that were readable by him. For example, I can telnet or ssh to my server and 'see' all my files. This is a different issue than accidently showing your Perl source in a browser.

CC.

On Saturday, December 29, 2012 1:51:15 PM UTC-5, E.D.G. wrote:
> Another option that I learned about a while back is to put an>
> index.html file in each subdirectory. And you can set the code in that file
> so that it redirects any subdirectory visitors back to the main .html file.>
> Then they can't see the subdirectory contents.

I don't like that at all. If you use CGI, you shouldn't have any HTML files-- all your HTML content should be generated by your CGI scripts. I invariably use one directory for the HTML content (mostly ONE(!) HTML file,one ormore CSS files, and perhaps varil\ous JS files, and another directory for the CGI files. I sometimes have other diretories with JPED and GIF files, and so on. I do't like to mix content types in the same directory.

> There are three octal numbers that are also associated with each
> subdirectory and file. And I believe that there is a way to set them so

Use chmod to change file permissions.

> Before posting that first note here I asked my Internet Server's
> technical support people how to set those permissions. But they did not
> have an immediate answer. That was a little surprising to me as they serve

I find this hard to believe. You should be able to chmod your own files.Read the man pages on chmod and umask. Also, read the Apache pages on CGi.

This can take a lot of effort to figure it out, but if you are persistent you should be able to reach proficiency after a while. You might want to slap Linux on an old machine and use it as a test box I have a Pentium and a Pentium Pro, one with only an 8G hard drive, that I run Linux, Apache, Perl,and PostgreSQL on, and you can really learn a lot by setting it all up.

You can probably pick up an old machine for free, or at most $50.00. A KVM switch will cost you $50.00 tops. Get someone's old and slow machine, hook it up with a KVM switch, and learn all you can.

CC.

On 2012-12-29 20:10, ccc31807 <> wrote:
> On Saturday, December 29, 2012 1:51:15 PM UTC-5, E.D.G. wrote:
>> Another option that I learned about a while back is to put an>
>> index.html file in each subdirectory. And you can set the code in that file
>> so that it redirects any subdirectory visitors back to the main .html file.>
>> Then they can't see the subdirectory contents.
>
> I don't like that at all. If you use CGI, you shouldn't have any HTML
> files -- all your HTML content should be generated by your CGI
> scripts.

Why?

hp


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

On Saturday, December 29, 2012 4:47:36 PM UTC-5, Peter J. Holzer wrote:
> > I don't like that at all. If you use CGI, you shouldn't have any HTML
> > files -- all your HTML content should be generated by your CGI
> > scripts.
>
> Why?

There are probably more than four approaches to creating HTML, but I'll only mention four.

First, you can write HTML by hand using a text editor (vim, Notepad, and others). The advantage is that it gives you exact control over your code. Thedisadvantages include the requirement of being fairly proficient at HTML, CSS, JavaScript, etc., and that you only get static pages.

As a sub-category, this is where i would put PHP, ColdFusion, ASP, JSP, andsimilar. To me the key to these is that the author embeds scriptlets in his HTML code, the intention being to free the author from knowing anything about programming. To me, embedding scriptlets in HTML is pretty close to hand writing HTML in the first place, which is why I put it here.

Second, you can use something like Dreamweaver, or even (horrors!!!) Word, to create your pages. The advantage is that you don't need to know a lot about the languages. The disadvantages include giving up control over your code and only creating static pages.

Third, you can use a CMS or templating system or a framework. I've never done this so I don't know the advantages or disadvantages.

Fourth, you can create your HTML pages dynamically, with Perl, Python, Ruby, Java, all the way up to using C, Common Lisp, or something else. The mindset of this is that the author (programmer) writes code that outputs HTML. You still need to know HTML and in addition you need to know a programming language. The great (overwhelming) advantage is that you have all the powerof the programming language at your disposal. The difference between this and the first three is the difference between building your products one piece at a time, and building a factory that can automate the building of your products.

I started by writing HTML by hand. Then, I learned that you could use Perl to automate the tasks. I try my best to write in the functional style and write some pretty crude DSLs to help (e.g., a SQL.pm, an HTML.pm, a CONSOLE.pm, etc.) so my 'main' functions is just a series of function calls based on the query parameters passed on in the HTTP request.

It's actually quite easy in that you can build a very large website with not much code, and it turns out easy to maintain. This is how I imaging Amazon, eBay, and others do it. They OBVIOUSLY don't have a large team of authors hand coding each individual page that any user could conceivably request.

In short, I like the idea of building a factory to spit out HTML rather than handcrafting each HTML page individually.

CC.

----------rough example-----------

#! perl
use warnings;
use strict;
use CGI;
use HTML; #custom pm

my @query_params = param('query_params');

print "Content-type: text/html\n\n";
HTMLrint_header(@query_params);
HTMLrint_menu(@query_params); #top nav bar
HTML;print_content(@query_params);
HTMLrint_menu(@query_params); #bottom nav bar
HTMLrint_footer(@query_params);

exit(0);

On 29/12/12 21:10:51, ccc31807 wrote:
> This can take a lot of effort to figure it out, but if you are
> persistent you should be able to reach proficiency after a while.
> You might want to slap Linux on an old machine and use it as a test
> box I have a Pentium and a Pentium Pro, one with only an 8G hard
> drive, that I run Linux, Apache, Perl, and PostgreSQL on, and you
> can really learn a lot by setting it all up.

+1

> You can probably pick up an old machine for free, or at most $50.00.
> A KVM switch will cost you $50.00 tops. Get someone's old and slow
> machine, hook it up with a KVM switch, and learn all you can.

Don't bother with a KVM switch : you won't need it. Use a keyboard and
a monitor from another machine while your installing Linux. Once you
can access it via ssh, detach the keyboard and monitor, and do the rest
remotely. That is, after all, what you're trying to teach yourself.


Hope this helps,

-- HansM

On Sunday, December 30, 2012 11:35:12 AM UTC-5, Charlton Wilbur wrote:
> 2000 called: it wanted to point out that the important one you omitted
> is using a web application framework with a solid templating system, so
> that you put your logic in one place and your presentation in another.

You must have missed this:
"Third, you can use a CMS or templating system or a framework. I've never done this so I don't know the advantages or disadvantages."

I tried, got frustrated because it did what I did not want and didn't do what I wanted, so I wrote my own.

CC

On 2012-12-30 04:43, ccc31807 <> wrote:
> On Saturday, December 29, 2012 4:47:36 PM UTC-5, Peter J. Holzer wrote:
>> > I don't like that at all. If you use CGI, you shouldn't have any HTML
>> > files -- all your HTML content should be generated by your CGI
>> > scripts.
>>
>> Why?
>
> There are probably more than four approaches to creating HTML, but I'll only mention four.
[...]
> In short, I like the idea of building a factory to spit out HTML
> rather than handcrafting each HTML page individually.

I don't think you answered the question: Why should all HTML content be
generated by CGI IF there is one CGI script on the site?

Suppose I have a website with 100 static HTML pages. Every now and then
I add a new static page. Now, for some reason, I want to add some
content which cannot be represented in a static page, so I add a CGI
script. Why should I convert my 100 static pages to CGI at this point?

Or a more complex example: I have a web site with a few dozen GB of
static content, a Java-based CMS and web shop and a CGI based database
interface. Why should that not be allowed? What do I gain by putting the
static content behind a CGI script? Or, even worse,

There are reasons why it may be useful to keep static content in a
different form (database, files in XML or Wiki syntax, ...) and generate
the final HTML on the fly (e.g. consistent layout, more flexible, reuse
of content, ...). But none of these has anything to with whether some
other content on the site is generated with CGI.

hp

--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel