writing zero bytes in bash

[Mihai Maties]

On Saturday 26 February 2005 09:32, Russell Coker wrote:
> It opens the file with O_CREAT (so if you were to do `echo -n "" >
> /tmp/flag` to create a flag file then it would work as expected), but never
> calls the write(2) system call.
>
> To unset the fscreate or exec context you have to call write(fd, X, 0) (the
> value of X doesn't seem to matter as the kernel code doesn't dereference
> it).

As a sidenote, dd behaves the same. dd if=/dev/null of=something does not call 
write(2) because it doesn't need to write anything. Since no records were 
read it assumes that no records must be written. Again, the output file would 
be created because of the open("something", O_CREAT) call.

> It seems likely to me that there may be other bits of kernel code exporting
> an interface under /proc where a write of 0 bytes may have a different
> meaning to merely opening a file with write access and then closing it.

Then this is the problem, not bash, dd or whatever.

> So it seems reasonable to me to consider this to be a bug in bash where
> it's optimisation of shell code results in the action requested by the user
> not being performed correctly.

It's quite logical since if you do not have something to write, to not try to 
write it.

> It took a surprising amount of time for me to realise that bash wasn't
> doing what I expected of it and ran strace to prove it.  I expect that most
> sys-admins would take even longer to work it out (if they ever did).

This is indeed a problem, but the solution is not patching bash, dd, whatever.

> I expect that the bash developers may disagree with this assessment so I
> would like some more input on the lists before I file a bug report.

If I were a bash developer I would disagree with you :) You would ask me to 
make a workaround in bash to solve an issue that has its roots somewhere 
else...


Mihai