When hosting an application on 'your.host', you normally have passive files and executable files. Passive files are things like 'html', 'php', 'gif' or 'jpg' (pictures), etc. The executable files are things like 'perl' or Unix scripts ('ksh', 'bash'), etc. Most hosting sites keep these two types of files in separate places. Passive files are usually kept in 'public_html' or 'Sites' or 'WWW' directories owned by individual accounts on the host. Executable files are usually kept in 'cgi-bin', which either is owned by individual accounts (like 'public_html'), or is owned by the system and therefore serves all accounts on the host. Different hosts do it different ways. Here are just a few: 1. Macintosh - Darwin System Individal accounts have their own 'Sites' directory for 'html', etc. There can be sub-directories in Sites to hold collections of passive files related to a single application. The 'href' or 'img src' reference to these files look like this: http://your.host/~yourname/yourfile.html http://your.host/~yourname/your_subdir/yourfile.php http://your.host/~yourname/images/yourpict.jpg Notice that 'Sites/' doesn't appear. It is assumed after yourname/. There is a system-owned '/Library/WebServer/CGI-Executables' that defines 'cgi-bin'. All executable files must be in 'cgi-bin' or sub-directories of 'cgi-bin'. For example, there can be a 'yourname' sub-directory that contains executables just for your account. That's the easiest way to allow multiple users to have their own executables. Of course there could be executables in 'cgi-bin' itself that either are general purpose, or are targeted to individuual accounts. 'href' references to executables look like this: http://your.host/cgi-bin/printenv.pl http://your.host/cgi-bin/yourname/suspires.pl The last example shows a reference to a privately owned suspires.pl perl script. That script might define an ENVironment variable that supplies 'yourname', such as: export USER='yourname' so the script can communicate the owner's name to other executable processes. That's basically the only way those processes will know how to built 'href' or 'img src' references to ~yourname 'Sites' passive files. 2. AFS systems (Linux or Unix) Most Linux AFS systems have 'WWW' for passive files, and 'cgi-bin' for executables, but generally they are BOTH privately owned by individual accounts. Therefore, ~yourname is in every 'href' or 'img src', but 'WWW/' is NOT given, just like for 'Sites/' in Darwin systems. The 'href' references look like this: http://your.host/~yourname/yourfile.html http://your.host/~yourname/your_subdir/yourfile.php http://your.host/~yourname/images/yourpict.jpg http://your.host/~yourname/cgi-bin/printenv.pl http://your.host/~yourname/cgi-bin/suspires.pl Basically, your HOME directory has both 'WWW' and 'cgi-bin' directories and the executables are held in 'cgi-bin'. Your 'suspires.pl' script would still do: export USER=yourname to insure consistent processing. 3. WebAuth systems (Linux or Unix) These systems are like AFS systems, but only ONE account is authorized to act as a Web Server. Therefore, '~yourname/' is dropped from 'href' and so is 'cgi-bin/' leaving just these forms of 'href' references: http://your.host/yourfile.html http://your.host/your_subdir/yourfile.php http://your.host/images/yourpict.jpg http://your.host/printenv.pl http://your.host/suspires.pl Everything is in 'public_html' and nested sub-directories. Both passive and executable files are together. Your 'suspires.pl' script could still do: export USER=yourname to insure consistent processing. But you would also drop '~yourname/' from generated html output. WebAuth systems always assume ~yourname/public_html as the target directory. Lastly, when generating or writing 'html' or 'php' files, you generally can leave out 'http://your.host' from the 'href' or 'img src' statements. These are known as 'relative to base' references. Depending upon the system, everything that follows that string would still be specified. Macintosh: /~yourname/images/yourpict.jpg /cgi-bin/printenv.pl AFS: /~yourname/images/yourpict.jpg /~yourname/cgi-bin/printenv.pl WebAuth: /images/yourpict.jpg /printenv.pl There are two other popular forms of 'relative' reference. One has a './' start instead of just '/'. The leading dot says: "Everything up to the last slash in the path that got to the current web page." Thus, if your 'item.html' was obtained from the following URL: 'http://your-host/~yourname/sub-dir/item.html' then './' means everything except 'item.html', so whatever follows './' is either a new.html or path extention to a new.html reference. Thus: './new.html' becomes 'http://your-host/~yourname/sub-dir/new.html'. The other form is '../' which acts like './' but would eliminate 'sub-dir/' from the path. In other words, it backs over sub-dir.
Click on this link to return to the main SUSPIRES index.