Test failure in redirect.

Test failure in redirect.

[Felix Rosencrantz]

Another test failure related to the latest changes.  -FR.

./A04redirect.ztst: starting.
Test ./A04redirect.ztst failed: bad status 1, expected 0 from:
  print foo >&-
Error output:
(eval):print:1: write error: bad file descriptor
Was testing: '>&-' redirection
./A04redirect.ztst: test failed.

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

Re: Test failure in redirect.

[Bart Schaefer]

On Jan 30, 10:41pm, Felix Rosencrantz wrote:
} Subject: Test failure in redirect.
}
}   print foo >&-
} Error output:
} (eval):print:1: write error: bad file descriptor

This is of course a result of the error-checking that Clint added to
bin_print().

--- ../zsh-forge/current/Src/builtin.c	Sun Jan 27 15:17:26 2002
+++ Src/builtin.c	Mon Feb  4 10:43:46 2002
@@ -3074,10 +3074,12 @@
 	    } while (*ap);
 	    fputc(ops['N'] ? '\0' : '\n', fout);
 	}
-	if (((fout != stdout) ? fclose(fout) : fflush(fout)) != 0) {
+	/* Testing EBADF special-cases >&- redirections */
+	if ((fout != stdout) ? (fclose(fout) != 0) :
+	    (fflush(fout) != 0 && errno != EBADF)) {
             zwarnnam(name, "write error: %e", NULL, errno);
             ret = 1;
-        }
+	}
 	return ret;
     }
     
@@ -3090,11 +3092,12 @@
 	}
 	if (!(ops['n'] || nnl))
 	    fputc(ops['N'] ? '\0' : '\n', fout);
-	if (((fout != stdout) ? fclose(fout) : fflush(fout)) != 0) {
+	/* Testing EBADF special-cases >&- redirections */
+	if ((fout != stdout) ? (fclose(fout) != 0) :
+	    (fflush(fout) != 0 && errno != EBADF)) {
             zwarnnam(name, "write error: %e", NULL, errno);
             ret = 1;
 	}
-	
 	return ret;
     }
     
@@ -3279,9 +3282,11 @@
 		}
 		zwarnnam(name, "%s: invalid directive", start, 0);
 		if (*c) c[1] = save;
-		if (((fout != stdout) ? fclose(fout) : fflush(fout)) != 0) {
-	            zwarnnam(name, "write error: %e", NULL, errno);
-	        }
+		/* Testing EBADF special-cases >&- redirections */
+		if ((fout != stdout) ? (fclose(fout) != 0) :
+		    (fflush(fout) != 0 && errno != EBADF)) {
+		    zwarnnam(name, "write error: %e", NULL, errno);
+		}
 		return 1;
 	    }
 
@@ -3345,9 +3350,11 @@
 	/* if there are remaining args, reuse format string */
     } while (*args && args != first && !ops['r']);
 
-    if (((fout != stdout) ? fclose(fout) : fflush(fout)) != 0) {
-        zwarnnam(name, "write error: %e", NULL, errno);
-        ret = 1;
+    /* Testing EBADF special-cases >&- redirections */
+    if ((fout != stdout) ? (fclose(fout) != 0) :
+	(fflush(fout) != 0 && errno != EBADF)) {
+	zwarnnam(name, "write error: %e", NULL, errno);
+	ret = 1;
     }
     return ret;
 }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Test failure in redirect.

[Zefram]

Bart Schaefer wrote:
>}   print foo >&-
>} Error output:
>} (eval):print:1: write error: bad file descriptor
...
>+	/* Testing EBADF special-cases >&- redirections */
>+	if ((fout != stdout) ? (fclose(fout) != 0) :
>+	    (fflush(fout) != 0 && errno != EBADF)) {

I think the error message is correct and should remain; the test data
is what needs to be fixed.

-zefram

Re: Test failure in redirect.

[Bart Schaefer]

On Feb 4,  9:03pm, Zefram wrote:
} Subject: Re: Test failure in redirect.
}
} Bart Schaefer wrote:
} >}   print foo >&-
} >} Error output:
} >} (eval):print:1: write error: bad file descriptor
} ...
} >+	/* Testing EBADF special-cases >&- redirections */
} >+	if ((fout != stdout) ? (fclose(fout) != 0) :
} >+	    (fflush(fout) != 0 && errno != EBADF)) {
} 
} I think the error message is correct and should remain; the test data
} is what needs to be fixed.

I don't think so ... closing stdout should not produce an error from a
builtin that does output.  E.g. here's bash:

[schaefer@zagzig schaefer]$ echo foo >&-
[schaefer@zagzig schaefer]$ echo $?
0
[schaefer@zagzig schaefer]$ 

The "print" command has to execute, e.g. in case it's given -P and there
are side-effects of the prompt expansion due to the PROMPT_SUBST option,
but it must not produce any output and it definitely shouldn't return 
nonzero.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Test failure in redirect.

[Zefram]

Bart Schaefer wrote:
>The "print" command has to execute, e.g. in case it's given -P and there
>are side-effects of the prompt expansion due to the PROMPT_SUBST option,
>but it must not produce any output and it definitely shouldn't return 
>nonzero.

The print command's purpose is to write certain characters to stdout.
In this case, it is unable to perform that operation, because stdout
isn't connected to anything.  Why should the treatment of that case
differ from the case where it is unable to perform the intended operation
due to stdout being on a full filesystem?  It seems to me that an error
message warning of the failure is appropriate in either case.  Is there
any precedent for echo/print being silent about a closed stdout but
complaining about other error conditions?

The only argument I see for not treating a closed stdout as an error
when one attempts to write to it is to allow >&- to be used to throw
away output.  What's wrong with >/dev/null?  Is there a significant
amount of code that uses >&- instead of >/dev/null?  I argue that such
code is broken.

>E.g. here's bash:
>
>[schaefer@zagzig schaefer]$ echo foo >&-
>[schaefer@zagzig schaefer]$ echo $?
>0
>[schaefer@zagzig schaefer]$ 

I get results inconsistent with that:

	zefram@bowl:~> echo foo >&-; echo $?
	1
	zefram@bowl:~> echo foo >/dev/full; echo $?
	1
	zefram@bowl:~> echo foo >/dev/null; echo $?
	0
	zefram@bowl:~> echo $BASH_VERSION
	2.05a.0(1)-release

How does your version handle >/dev/full?  I get identical results from
pdksh, by the way (i.e., >&- and >/dev/full both treated as errors,
$?=1 but no error message).

-zefram

Re: Test failure in redirect.

[Bart Schaefer]

On Feb 5,  2:46am, Zefram wrote:
}
} Is there any precedent for echo/print being silent about a closed stdout
} but complaining about other error conditions?

I'd be happy with reverting it to the old state where it was silent about
all write errors.  It was changed because of a Debian bug report; the
precedent, if any, was embodied in A04redirect.ztst.

We generally haven't created tests for behavior that was known to be wrong
without in some way marking it as such.  As the test code from more than a
year ago was specifically testing for successful exit of print to a closed
stdout, somebody (probably PWS) must at some point have believed that to
be the correct behavior.

} The only argument I see for not treating a closed stdout as an error
} when one attempts to write to it is to allow >&- to be used to throw
} away output.  What's wrong with >/dev/null?

There's no requirement that /dev/null exist in order for zsh to compile
and run.  There has in the past been a pure Windows port of zsh, even
though it's sort of been superceded by the Cygwin build now.

} Is there a significant amount of code that uses >&- instead of >/dev/null?

I couldn't say if there's a "significant" amount, but closing stdout to
supress output was not an uncommon scripting hack in the past.  (I'd say
the "distant" past, but that would make me feel old.)

} >E.g. here's bash:
} >
} >[schaefer@zagzig schaefer]$ echo foo >&-
} >[schaefer@zagzig schaefer]$ echo $?
} >0
} >[schaefer@zagzig schaefer]$ 
} 
} I get results inconsistent with that:
} 
} 	zefram@bowl:~> echo foo >&-; echo $?
} 	1
} 	zefram@bowl:~> echo foo >/dev/full; echo $?
} 	1

I get $? of 0 for both of those, with bash-2.0.3.  So even returning an
error status is a fairly recent development.

} How does your version handle >/dev/full?

bash-2.0.3 gives no error message and returns 0 on write to /dev/full.
(I verified that `cat > /dev/full' on the same machine gives the "no
space on device" error.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net