Link to basic bash scripting e-guide
 

Hi,

Can any one guide me to download and learn basic bash scripting.. and e-tutorial or pdf or doc ..

Thanks

There are several guides to bash. Try one of these:
http://www.physics.ohio-state.edu/~n...ompt-HOWTO.pdf
http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html

And also
http://www.tldp.org/LDP/abs/html/
http://rute.2038bug.com/index.html.gz

Thanks al2.. Its helps me a lot to server my job..
Moreover.. chrism01.. can you help me in the 2nd link.. its a zip file which when I saved.. then the path is not correctly mentioned or what.. no link is opening... can you guide me... how to work with
http://rute.2038bug.com/index.html.gz

Thanks anyway to both of you for you assistance

This opens on my system with no problems. (Firefox 2.0.0.11)
I've never seen the .gz extension on html pages....

This is weird: If I save the page to disk and then try to open it, it offers only to open with Ark. This fails, as does double-clicking. I also cannot open the saved file from within FF (even though FF opens it from the site just fine).

If I rename the file with just the .html extension, it opens normally.

AND--if I try to put it in the address line without the .gz, it gives me this:

Conclusion: When I save the page, it is no longer compressed, but it keeps the .gz extension.

Solution: save and rename the file, or use Firefox/Mozilla

It’s not that weird. The reason is that file extensions are immaterial to web browsing. Most likely, the file extension is there to tell the server how to treat the file. In this case, the .gz extension tells the server to use web compression to send the file if the client advertises itself with “Accept-Encoding: gzip” (which Mozilla browsers do). So the compressed content is transmitted by the server to the web browser where it is decompressed and interpreted as “Content-type: text/html” (all transparent to the user). When you try to “Save Page” through the webbrowser, the decompressed version will be saved, with whatever filename you chose (including file extension).

If you try to open the file later on (you are no longer web browsing, but file browsing), there is no server to tell the browser how to interpret the file (i.e., give it a Content-type). The only hint it has is the file extension (even if the extension misrepresents the file). So if you have an html text file with a different extension (e.g., .gz), the browser will assume (without looking at the contents of the file) that the MIME-type corresponds to that extension (e.g., application/x-gzip) instead of text/html.

If you try this sort of thing in something like wget, you will have to decompress the file yourself. E.g.,
As you can see, the file is sent to be interpreted as text/html even though it is encoded with gzip.

OK--replace "weird" with "I've never seen it before." (In thousands of hours of web browsing.)

Is the browser response to a g-zipped file in the W3C standards?

When Firefox saves a file with the .gz extension--but which is no longer a g-zip file--is that standards-compliant? If so, find me the people that maintain these standards.....:mad::mad:

You probably have seen web compression, it’s just usually done completely transparently (e.g., even if the stream is compressed, you won’t notice any extensions in the URI).
The browser (when browsing through http) doesn’t (or shouldn’t) have a clue of the file types corresponding to various paths (i.e., it shouldn’t try to interpret extensions). What it should do is send a request to the server (consisting mostly of a host and an absolute path), and interpret the response based on the entity headers (again not by looking at the extension). For example, if the headers indicate the Content-Type to be “application/x-gzip” with no Content-Encoding, then the browser should use its application/x-gzip handler (usually saving the file to disk or opening a temporary copy with an external program). This is what happens with most URIs which end in “.gz” (e.g., http://www.kernel.org/pub/linux/kern...-2.6.23.tar.gz). If the headers indicate the Content-Type to be “text/html” with a Content-Encoding of “gzip”, then the browser should decompress the stream and handle the result with the text/html handler (which is usually the browser itself). This is what happened with the RUTE URI. The choice of the headers themselves is made by the server (not the browser).

For example, some servers chose to send files which end in “.c” over as “text/plain”, and others chose to use “text/x-csource” or “application/octet-stream”. The difference often means the difference in a browser showing the contents of the file or opening up the default editor to show the contents. A similar thing happens for postscript files (e.g., if sent as “text/plain” you are shown the source code for the postscript file, but if sent as “application/postscript” it is opened by a postscript viewer). If I wanted, I could mismatch all the file extensions on my server, as long as I told you how to use them correctly. The only time the browser will try to read the extensions itself is when the Content-Type is given as “application/octet-stream”.

All this is in the “standards”. Mostly it is in the HTTP standard (RFC 2616).
Well on my firefox, this is what happens: I go to “File->Save Page As” and a subsequent save dialog is given. It asks me where to save it and what the filename should be. The default place to save it is my home directory, and the default filename is usually the basename of the absolute path portion of the URI. I don’t think the W3C or any other standards body cares what choice of default filename a browser uses. I am not even aware that the W3C mandates a browser to have “Save Page” functionality.

Also check this: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html (for gzip compression)

Actually, that server has two different files.

One is named index.html, which contains 640 bytes of HTML that display the message you quoted.

The other is named index.html.gz, which is the 20378-byte gzip file.

This LINK will get you the whole book so you can read it offline.
The BashFAQ
The BashGuide