🚀 go-pugleaf

>In article <42651@unlisys.in-berlin.de> rot@unlisys.in-berlin.de (Robert Rothe) writes:
>
>>the other is a redirection-bug ! if you use '> /dev/device' it
>>will always complain: cannot clobber existing file - when noclobber
>>is set. if noclobber is not set - bash will try to unlink the file
>>and recreates it. that is a strange behavior.
>
I don't think this is right.  I've tried commands like
echo foo > /dev/tty
echo foo > `tty`
cat /etc/profile > /dev/tty
cat /etc/profile > /dev/tty01
etc., etc., with bash1.08p1, as further patched with the diffs that I
posted, and with the fixed "getcwd.c".  All of these commands worked
correctly -- whether or nor "noclobber" was set.

In answer to Robert's posting, Chet writes:

>As much as I hate to say it, this sounds like an OS bug.  With noclobber
>set, bash checks the target of output redirection and complains only if the
>file is a `regular' file (that is, S_ISREG (statbuf.st_mode) returns
>non-zero).  Devices in /dev are supposed to be either character-special or
>block-special.
>
>When noclobber is not set, bash tries `open' with a flags argument of
>O_TRUNC | O_WRONLY | O_CREAT.  It never tries to unlink the file.
>
>As a test, see what test -c /dev/device or test -b /dev/device return,
>using $?.  One of them should give $? == 0.  Then see what test -f /dev/device
>returns.  It should always be 1.  Here's what I get on a Sun-4 running
>SunOS 4.1:
>
>odin$ tty
>/dev/ttyp5
>odin$ test -c $(tty)
>odin$ echo $?
>0
>odin$ test -b $(tty)
>odin$ echo $?
>1
>odin$ test -f $(tty)
>odin$ echo $?
>1
>
>My terminal, /dev/ttyp5, is therefore a character special device.

I tried it, and get exactly the same results under ISC 2.2 with bash1.08p1,
and the patches that I posted previously.

I don't understand why Robert got different behavior.

On a different tack:

I've downloaded gcc1.40, and ran the fixincludes script on it.  It did a
good enough job on the ISC 2.2 headers, that I was able to compile bash1.08p1
with the ISC 2.2 diffs, with "gcc -posix" rather than "gcc -posix -traditional".
The resulting "bash" is a bit smaller, and seems to work the same.  (Some
minor fixes are needed, for ANSI C prototype checking, here and there.)

		Yours sincerely,

		Saul Lubkin