Hi all, I am trying to learn

whoami — Thu, 30 May 2013 07:59:39 +0000

Hi all,

I am trying to learn perl scripting.Can some one suggest me the best way to start up.Please keep in mind that i dont even know the basics

Mark Hensler — Tue, 10 Jun 2003 05:45:52 +0000

I'm surprised it worked. hehe... Perl is not my forte. I just dable a bit here and there.

Believe it or not, I learn a heck of a lot researching for answers to people's questions. I'm looking forward to providing assistance in the future.

critical — Tue, 10 Jun 2003 00:35:46 +0000

It worked!

Mark, thank you for the continued feedback and ideas, and seeing this through to the end.

And be on the look-out for my upcoming thread about file uploads! :-)

Mark Hensler — Sun, 08 Jun 2003 22:03:57 +0000

Try chomping the line.

open(LOG, "anything.txt");
while(<LOG>) {
    chomp;
    print $_, "\r\n";
}
close(LOG);

critical — Sat, 07 Jun 2003 17:41:10 +0000

Thanks Mark - that's very interesting. Here's what I found out:

open(LOG, "anything.txt");
my @file_array = ;
close(LOG);

print "Content-disposition: attachment; filename=anything.txt\n\n";

# opens in Wordpad - but no line returns in Notepad
print @file_array;

-OR-

# opens in Notepad - extra line returns after each line in Wordpad
foreach my $dline (@file_array) {
print "$dline\r\n";
} # end for

So how the heck can I get the text file to open in *both* Notepad and Wordpad with the proper number of line returns??? Bizarre problem...

critical — Sat, 07 Jun 2003 17:39:58 +0000

see next post...

Mark Hensler — Fri, 06 Jun 2003 16:45:47 +0000

This isn't really a bug. More of a compatability issue.

The line seperator for different operatings systems is as follows:
win: \r\n
nix: \n
mac: \r

When you upload a .txt file via FTP in ASCII mode, it automatically makes the conversion for you (changing the line delimiter). But when you simply send the file as is, the conversion isn't being made.

Solution, upload your .txt files in binary mode. This will prevent the line delimiters from being converted between systems. However, this may cause other problems. (read errors on the unix machine)

critical — Fri, 06 Jun 2003 14:46:54 +0000

Well, it's been over a week... and my file download script is working great!

One quirk though:

If you download a plain text file - anything.txt - and open it in Notepad, the line returns are gone!!! All the lines of the original file just wrap around as one long line now!

If you open the downloaded text file in Wordpad or Excel, this does not happen - it displays properly.

Doesn't matter how you do the download, either:

print "Content-disposition: attachment; filename=anything.txt\n\n";
open(LOG, "anything.txt");
my @file_array = ;
close(LOG);

print @file_array;

_OR_

foreach my $dline (@file_array) {
print $dline;
}

Either of the above work the same way. Printing extra line returns (\n) doesn't help either.

I've seen this before. There's a bug in the Webmin application for Linux servers for example. When you use Webmin's file manager to edit a server's httpd directives, it saves the changes as one long line of text which is a serious problem.

Anybody know more about this? Why does it happen? How to keep it from happening? Is there any way to download a text file from a server (from a web page) so that the integrity of each line is maintained in both Notepad *and* Wordpad? Why is there a discrepancy in the way these two text editors included on every Windows PC interpret line-returns in a downloaded text file?

Thanks!

critical — Wed, 28 May 2003 13:43:04 +0000

Also: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q260/5/19.ASP&NoWebContent=1

Mark Hensler — Wed, 28 May 2003 06:50:31 +0000

Ah, found it...

Quotes from here: ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

15.5 Content-Disposition Issues

   RFC 1806 [35], from which the often implemented Content-Disposition
   (see section 19.5.1) header in HTTP is derived, has a number of very
   serious security considerations. Content-Disposition is not part of
   the HTTP standard, but since it is widely implemented, we are
   documenting its use and risks for implementors. See RFC 2183 [49]
   (which updates RFC 1806) for details.

19.5.1 Content-Disposition

   The Content-Disposition response-header field has been proposed as a
   means for the origin server to suggest a default filename if the user
   requests that the content is saved to a file. This usage is derived
   from the definition of Content-Disposition in RFC 1806 [35].

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )

   An example is

        Content-Disposition: attachment; filename="fname.ext"

   The receiving user agent SHOULD NOT respect any directory path
   information present in the filename-parm parameter, which is the only
   parameter believed to apply to HTTP implementations at this time. The
   filename SHOULD be treated as a terminal component only.

   If this header is used in a response with the application/octet-
   stream content-type, the implied suggestion is that the user agent
   should not display the response, but directly enter a `save response
   as...' dialog.

   See section 15.5 for Content-Disposition security issues.

'
(haha... one of the two writers of RFC 1806 lives in my city)