Strange "There is not enough space on the disk" error (Win32)

[bgreenlee]

I was writing simple test program to illustrate another issue I'm having, when I noticed some odd behavior (which is very likely related to the issue I'm having). If I run the following script on Windows, it works as expected:

#!perl -w

system("dir") == 0 or die "system failed: $?";

If I try to pipe the output to a file, however, I get an error:

C:\>test.pl > test.out
There is not enough space on the disk.
system failed: 65280 at C:\test.pl line 3.

(Yes, I have plenty of disk space available.)

If, however, I do "perl test.pl > test.out", it works fine.

I know there are other ways to do this, but I'm curious as to why this happens on Windows. I've searched high and low and haven't found anything so far.

Cheers,

[bmann]

cmd.exe has some issues with shell redirection and pipes if the file is not an executable program or a batch file.

Wrap your sample script using pl2bat, and that error goes away.

Hope this helps with your original problem as well... Sample output:

C:\S\temp>test.bat > test.txt

C:\S\temp>type test.txt
 Volume in drive C is Main
 Volume Serial Number is 280A-19E0

 Directory of C:\S\temp

01/07/2004  02:10p      <DIR>          .
01/07/2004  02:10p      <DIR>          ..
10/09/2003  04:24p                 193 two.lol
12/13/2003  11:46p              65,230 314563.lol
03/28/2005  09:01p                 481 test.bat
03/28/2005  09:14p                   0 test.txt
               4 File(s)         65,904 bytes
               2 Dir(s)  11,755,111,424 bytes free

[bgreenlee]

Do you have any info on the nature of cmd.exe's issues? I'm just really curious now as to what the underlying issue is.

pl2bat does work, although it's essentially just calling "perl test.pl", which I already know works. What I don't understand is, assuming you've got your .pl file association set up, what's the difference between just calling "test.pl", and "perl test.pl"?

The only thing I can think of is that when you force Windows to go out and find the associated program, it launches it in its own console rather than the existing one, and you somehow don't have access to that console's stdout (although you still get the output in your console, so...). Silly Windows.

[bmann]

Do you have any info on the nature of cmd.exe's issues?

I wish I did. Here's what perldoc pl2bat has to say about it:

---8<---
4
      C:> ftype Perl=perl.exe "%1" %*
      C:> assoc .pl=Perl
      then
      C:> script.pl [args]

5
      C:> ftype Perl=perl.exe "%1" %*
      C:> assoc .pl=Perl
      C:> set PathExt=%PathExt%;.PL
      then
      C:> script [args]
---8<---
4 and 5 work on some Win32 operating systems with some command shells.
One major disadvantage with both is that you can't use them in pipelin
+es
nor with file redirection. For example, none of the following will wor
+k
properly if you used method 4 or 5:

    C:> script.pl <infile
    C:> script.pl >outfile
    C:> echo y | script.pl
    C:> script.pl | more

This is due to a Win32 bug which Perl has no control over. This bug is
the major motivation for pl2bat [which was originally written for DOS]
being used on Win32 systems.

To paraphrase, it doesn't work because it doesn't work. ;)

All I can see (from this and some searching of MSDN) is that redirection and pipes break when you use ftype and assoc to run a script. I have never seen a why. It's useful information, just not very informative.

[graff]

I wish I could offer a proper explanation, but I don't know enough about the current versions of the cmd.exe (or command.exe?) shell and how they handle redirection or pipes -- let alone how they do this when the first word on the command line is the name of a perl script.

Just for grins, what if you use a windows port of the bash shell instead?

Also, I'm curious why would you use a system call to run "dir", rather than using the perl-internal "opendir...; readdir..."?

Or, if you're really committed to the idea of using a system call to run "dir", have you tried doing the redirection within the system call? (Would that work from the ms shell command line?)

[bgreenlee]

This is just a simple test to illustrate a problem. I really have no interest in "dir", actually...it was just the first Windows command I thought of that would generate some kind of output.

[MrStretch]

This is just a guess so don't yell if I'm wrong.

I believe the problem is that when installing perl you register .pl filehandles and what not, but you also put the perl path in your envirmental path variable. Now I would assume that you have that path because I'll assume you ommitted perl when you ran it without the " > test.out" and you get output when you run it with the perl ommitted.

At first i thought it was a problem with your shebang line; however, that isn't what is causing the problem because I still got that error when running it on a windows machine. Next I thought it might be from the -w. Crash and burn also. Then I struck gold. The problem is in your code itself. For some reason or another the command.exe shell is catching on you system call. It is not a problem with the shell. It is a problem with the code itself.

I believe it is because when you call a system command in perl, you send the command directly to the system, bypassing perl (except perl returns 1 or 0 for success). This somewhat confuses windows (for lack of a better term). This may not be the explanation you were looking for, but it's all i got.

[bgreenlee]

Well, the point of system *is* to execute a system command. There is no "system" function in cmd.exe anyway.

I think it may have something to do with Windows not being able to do a proper fork. Perhaps the way fork is done makes stdout unavailable, and you end up basically trying to redirect something null or undefined?

[ikegami]

Do you get the error if you do perl test.pl > test.out? I wonder how solid is Windows ability to accept commands that aren't .exe, .com or .bat.

What if you do it in a directory other than a root directory? Unlike subdirs, root dirs in a FAT system have a fixed size. When one tries to create too many files in the root directory, one gets an "out of disk space" error.

Does the directory referenced by %TEMP% exist? Is that drive full? How about %TMP%? Is your main drive full? Maybe something is trying to create a temporary file.

[bgreenlee]

I actually didn't run it in root originally; I just removed the directory info when I posted to simplify things. Yes, %TEMP% and %TMP% point to real directories, and there's plenty of disk space (I've tried this on two different machines, btw, same result).

[bibo]

Hi

Some info about what distro of perl you have installed would be helpful.

FYI, On my machine, if I did "perl simple.pl" I saw the dir listing. However, if I did "simple.pl" I got nothing, and eventually the windows "file association applet" appeared, asking me how to associate this command with a known application.

I'm guessing if you dig a bit into the docs for your distro, you will find out how they set up this file association, and perhaps give you a clue how to fix it. I see the DOS commands "ftype" and "assoc" may also be helpful in tracking this down.

Naturally, down deep, this is likely a Registry Thing, but hopefully you won't have to dig that far to fix this.

--b

[bgreenlee]

ActivePerl 5.8.6.811, on Windows XP. The file association isn't an issue; when installing ActivePerl I told it to go ahead and set up the .pl association for me. It certainly runs--when I just type "test.pl", I get my directory listing as expected. It's only when trying to redirect that output to a file that I run into problems.

[nerfherder]

I think to have associated the file type on the command line, something like this happened:

C:\>ASSOC .pl=PerlScript FTYPE PerlScript=perl.exe %1 %*

system("dir") == 0 or die "system failed: $? , $!, $^E";

gives:

C:\mydir\>test.pl > test.out
system failed: 65280, No such file or directory, %1 is not a valid Win32 application at C:\mydir\test.pl line 3.

I think that the problem is that a new shell is invoked from within the perl script, and the output of 'dir' can't make it back due to quirks in the ActivePerl implementation: http://perlhelp.web.cern.ch/PerlHelp/faq/Windows/ActivePerl-Winfaq5.html

I agree with the above; gotta use pl2bat.