in reply to Re: DOS directory naming in PERL?
in thread DOS directory naming in PERL?

Even simpler IMHO is to avoid double quoting anything that will not need interpolating. I also use this as a quick visual clue of where demons may hide ;-)

BTW, I didn't see the need for the "\r" in the print as in DOS\WIN32 the "\n" is really both CR and LF characters.

open OUT,'>C:\windows\foobar.txt';
print OUT "Ha!\n";
close OUT;

[download]

--
I'd like to be able to assign to an luser

Replies are listed 'Best First'.
Re: Re: Re: DOS directory naming in PERL?
by mr.nick (Chaplain) on Jan 19, 2001 at 22:39 UTC
    (grin). Sorry, I'm so used to writing Unix code that reads and writes to DOS-style files that I automatically did it.

    So you are saying that the Dos/Win32 version of PERL correct interprets \n as the CR/LF combo? Interesting.

[reply]
      See perldoc perlop, and look for "Quote and Quote-like Operators". \n is "virtual" with respects to Perl in that does not map to a single ASCII byte irrespective of OS. It assumes the OS's representation of a "newline". Under Unix, this is equivalent to \cJ. Under DOS/Windows, it's \cM\cJ. Likewise, I think \r behaves differently under MacOS as well, for the same reasons.
[reply]
[d/l]
[select]
Re: Re: Re: DOS directory naming in PERL?
by Anonymous Monk on Jan 20, 2001 at 09:42 UTC
    I would have to disagree. Single quotes work fine when you have a backslash followed by anything but a backslash, but if you try to use two backslashes together (as in '\\foo') they will escape into one backslash. Does anyone know how to avoid this? Strings like '\\\\192.168.1.1' to get \\192.168.1.1 are ugly.

    The best I could come up with is: 

    print <<'' . " is the UNC name"
\\192.168.1.1

    [download]
    But this leaves an extra newline at the end of the IP address. Am I missing something blatently obvious?
[reply]
[d/l]
[select]
      In any quoted string ("", '', qq{}, q{}, etc.), a double backslash must be interpolated as a single backslash, because a backslash is used to escape the quoting character(s). This makes it possible to get the one character string \ and the two character string \', with '\\\'' and '\\', respectively.

      Here-docs are the exception to this. One can always find a terminator, possibly several characters long, that doesn't appear within the string itself. Thus, backslashes are free to be regular characters in a here-doc.

      I don't think you're missing anything; this is just how strings work in Perl.

[reply]
[d/l]
[select]

        In any quoted string ("", '', qq{}, q{}, etc.), a double backslash must be interpolated as a single backslash, because a backslash is used to escape the quoting character(s). This makes it possible to get the one character string \ and the two character string \', with '\\\'' and '\\', respectively.

        I don't see what's wrong with having '\' mean \ and having '\'."'" or q<\'> mean \'. It's a little more typing, but personally if I was the creator of Perl I would sacrifice the special meaning of backslashes in single-quoted strings for more normality...oh well, I'll have to be content with a source filter or using here-docs. But...

        Here-docs are the exception to this. One can always find a terminator, possibly several characters long, that doesn't appear within the string itself. <

        This is something I've been thinking about. What if I'm quoting arbitrary user-supplied data in an eval()? I wouldn't want to remove any occurances of the here-doc terminator I was using -- that might upset users whose data contains my terminator. Even if the terminator is a long and rare word, there is still a chance of data/terminator clashing -- disallowing the terminator in the data seems very cargo-cult and wrong to me.

        I guess the best here-doc terminator in this case would be a randomly-generated one...if only Perl had a qb// operator to quote an arbitrary number of bytes. (__DATA__ doesn't do what I want, since it is only one section. And if I want multiple sections, I need separators. The same exact problem all over again. Oh wait -- I could just store the number of bytes inside each section of the DATA. But then I have an evil arbitrary limit on how much data the user can supply. Unless I use BER encoded integers. Too much work for me.)

[reply]

In Section Seekers of Perl Wisdom