I have a perl assignment I have a question about. I have to take a text file (gettysburgh.txt) and I have to alter it. I think my code is correct but when I run the program it says no such file exists. The file is saved on my computer so I was hoping someone could tell me what I was doing wrong.

#!/usr/bin/perl -w
# Assignment3Ex1.pl

use strict;

open(INFH, '<', 'gettysburgh.txt') or die $!;
open(OUTFH, '>', 'ex1out.txt') or die $!;

while (<INFH>) {
next if /^\s*$/;
	my @words = split;
	print OUTFH "$_\n" foreach @words;
}

close INFH;
close OUTFH;

try using the full path to the file:

open(INFH, '<', 'full/path/to/gettysburgh.txt') or die $!;

I find this open statement interesting... I always do something like this:

open(INFH,"[B]<[/B]\\full\\path\\to\\gettysburgh.txt") #on windows
open(INFH,"[B]<[/B]/full/path/to/gettysburgh.txt") #on unix

What I don't understand is the ,'<', construct... that's not something I usually do.

Window fully supports forward slashes in directory paths. It always has. You can start using them from now on. :)

This is the three argument style of open:

open(INFH, '<', 'full/path/to/gettysburgh.txt') or die $!;

Its safer to use than the two argument style:

I'm pretty sure its convered in the open() functions documentation:

http://perldoc.perl.org/functions/open.html

Yeah I use the forward slash "/" in windows as well and windows/perl supports it. One thing I HAVE found is that Apache for windows is the only app I have come across that supports directory (or folder-level) permissions. What I found was that if folders are set as read-only, the only way to take that attribute off and have apache (or mod-perl or cgi perl) control a particular directory is to go to the cmd line and use attrib to remove the read only traits at the folder level. That is the only windows-weirdness I have found (and I found it with Apache 2 only).

As for the 3 argument open statement, I have never seen it before, but, perhaps, if that is the way they teach it, I should start using it - haha.

Mike

Window fully supports forward slashes in directory paths. It always has. You can start using them from now on. :)

This is the three argument style of open:

open(INFH, '<', 'full/path/to/gettysburgh.txt') or die $!;

Its safer to use than the two argument style:

I'm pretty sure its convered in the open() functions documentation:

http://perldoc.perl.org/functions/open.html

I'm pretty sure windows does not support paths with / as the separator. Try this: cd / or cd /windows and then try this cd \windows . What I'm guessing happens here, is Perl (and other languages that do this, such as python) are smart enough to know that even though we hacker-esque folks use / in a path, that we really mean \, and naturally adjusts it

Comatose,

You are correct at the shell level. - windows does NOT do that. I use the double backslashes in a file path because I usually set a data or file path (like $DATAROOT="\\a\\b\\c") and then substitute stuff in double quotes, rather than single - in which the double back quotes on windows work far better (i.e. "$DATAROOT\\$morepath\\$filespec"). Perl, python, ruby, java, etc. are smart enough to translate. Also, cygwin, which I always install on my windows systems (and which can use bash - which I love - btw I am I unix guy suffering through windows) can also do that translation. But ultimately, you are correct, the regular windows shell does NOT do that translation, only the apps - i.e. perl, python, ruby, cygwin do that.

Mike

I'm pretty sure windows does not support paths with / as the separator. Try this: cd / or cd /windows and then try this cd \windows . What I'm guessing happens here, is Perl (and other languages that do this, such as python) are smart enough to know that even though we hacker-esque folks use / in a path, that we really mean \, and naturally adjusts it

I'm pretty sure windows does not support paths with / as the separator. Try this: cd / or cd /windows and then try this cd \windows . What I'm guessing happens here, is Perl (and other languages that do this, such as python) are smart enough to know that even though we hacker-esque folks use / in a path, that we really mean \, and naturally adjusts it

Thats DOS (or other shell), not Windows. DOS uses forward slashes as switches, so you can't use them in directory paths. But Windows does fully support them. Its Windows itself that translates forward slashes into backslashes. Try using backslashes in Unix directry paths with perl or python and see what happens.

You can see here listed under directory paths for Windows:

http://en.wikipedia.org/wiki/Path_(computing)

In fact they list DOS as also accepting both \ / in directory paths. Maybe there is a way in DOS to change the path seperator. But when I try it it does not work in DOS, but it does in Windows.

Interesting. Like I said, I have cygwin installed and it gives me the unix commands (ls, grep, pwd, etc.) and it gives me bash in dos/windows. I always thought that that was why I got / to work. I put cyg-win before windows commands in my system so when I "cd" i am using the unix-ish version, not dos or windows.

You can see here listed under directory paths for Windows:

http://en.wikipedia.org/wiki/Path_(computing)

In fact they list DOS as also accepting both \ / in directory paths. Maybe there is a way in DOS to change the path seperator. But when I try it it does not work in DOS, but it does in Windows.

Thats DOS (or other shell), not Windows. DOS uses forward slashes as switches, so you can't use them in directory paths. But Windows does fully support them. Its Windows itself that translates forward slashes into backslashes. Try using backslashes in Unix directry paths with perl or python and see what happens.

Oddly enough, the above posted (with the suggestions to try cd / and cd /windows and cd "/documents and settings") was tested in windows XP SP1. I went to start... run, and typed in cmd. Once the window was up, I typed cd /, and hit enter. While XP didn't completely flip out, it certainly did not take me to the root directory (\). Then, when I typed cd /windows/system32, this most certainly did error. Try it with a known branch, such as: cd /windows/system32. No can do. Notice the second entry of the command line... gives an error. The third (using \'s) does not. The rest of the lines... none of them work either (although, the cd / doesn't error, it also doesn't work.). This is not DOS. This is cmd.exe (not command.com). However, KevinADC is right that explorer.exe (windows Desktop shell) does allow the use of / in paths (such as typing a path in my computer's location bar). The question is... is that the file system, or is that explorer.exe?

According to O'Reilly & Associates (Section 2.2.2, point / bullet number 2, and the table in 2.2.4) Some Perl modules and functions allow the use of '/' as a path separator, but it is strongly discouraged as a use of good practice.

Attachments pic2.png 19.18 KB

I trust O'Reilly significantly more than wikipedia. I also read on MSDN (will post when I get home) that it's the API calls and programs that do the translation, not NTFS Native.

I have always had more success at the cmd line (for windows) with perl using "\\path\\file.txt" However, in a web environment (at least if you're running apache for windows) "/path/file.txt" works just fine.

That has been my experience anyway.

Just to add a bit to the discussion. I was reading the perl FAQs to answer a question on a forumand came upon this:

Why can't I use "C:\temp\foo" in DOS paths? Why doesn't `C:\temp\foo.exe` work?

Whoops! You just put a tab and a formfeed into that filename! Remember that within double quoted strings ("like\this"), the backslash is an escape character. The full list of these is in "Quote and Quote-like Operators" in perlop. Unsurprisingly, you don't have a file called "c:(tab)emp(formfeed)oo" or "c:(tab)emp(formfeed)oo.exe" on your legacy DOS filesystem.

Either single-quote your strings, or (preferably) use forward slashes. Since all DOS and Windows versions since something like MS-DOS 2.0 or so have treated / and \ the same in a path, you might as well use the one that doesn't clash with Perl--or the POSIX shell, ANSI C and C++, awk, Tcl, Java, or Python, just to mention a few. POSIX paths are more portable, too.

I think I changed it to what some of the posts are saying but its still not working. This is what Ive got.

#!/usr/bin/perl -w
# Assignment3Ex1.pl

use strict;

open(INFH, '<', "C:\Documents and Settings\Home\Desktop\perl\gettysburg.txt") or die $!;
open(OUTFH, '>', 'ex1out.txt') or die $!;

while (<INFH>) {
next if /^\s*$/;
	my @words = split;
	print OUTFH "$_\n" foreach @words;
}

close INFH;
close OUTFH;

I trust O'Reilly significantly more than wikipedia. I also read on MSDN (will post when I get home) that it's the API calls and programs that do the translation, not NTFS Native.

Its windows itself. Support for forward and backslashes in builtin to Windows. You can google around and find MicroSoft articles that explain it if interested. I think thats enough on the subject.

If it were windows itself, don't you think cmd.exe (which is a windows program) would support it? I would imagine so. According to MSDN (I was holding off on it, but will post it when I get home) they say it's the API functions that translate the / slashes to \ slashes. That would mean it's not windows itself (ie: the file system) but the programs that are running on it (ie: explorer.exe, and so forth). Just for fun, try this:
start, run, type in: /
Oops.
Start, run, type in: \
interesting.

http://www.cygwin.com/cygwin-ug-net/using-effectively.html <<-- Under Pathnames
And straight from the horse's mouth:
http://msdn.microsoft.com/en-us/library/aa989022(VS.80).aspx

I guess when we say Windows we should be more specific. Windows operating systems based on NT are different than older operating systems. The older ones support both slashes at the kernel level where NT does not. NT based systems do a conversion before the kernel level (in the APIs apparently). I had a link that explained all this on the MS website but the link now returns a "not found" page.

This article has been dead for over six months. Start a new discussion instead.