Fix the remaining handful of failing tests in tarball (stable) m4
Opened this issue · 5 comments
Current list is:
Failed checks were:
./005.command_li:out ./006.command_li:out ./006.command_li:err ./137.include:err
#5: If I run:
echo | cat >&- 2>/dev/null
echo $?
from 'bash', I get 0 (this is not what is expected - the file descriptor &- should be invalid).
If I run the same sequence of 2 instructions from 'sh', I get 1.
If I run
m4 <test.m4, where test.m4 is:
syscmd(`echo | cat >&- 2>/dev/null')ifelse(sysval, `0',
`errprint(` skipping: system does not allow closing stdout
')m4exit(`77')')dnl
changequote(`[', `]')dnl
syscmd([echo | ']__program__[' >&-])dnl
sysval
on my Mac, I get:
/usr/bin/m4: write error: Bad file descriptor
1
whereas on z/OS (either inside sh or inside bash) I get:
0
I thought this might be a more general problem where 'sysval' was not being correctly set, but this works:
esyscmd(`echo "jello" | grep "hello world' ")ifelse(sysval, `0',
`errprint(` skipping: system does not allow closing stdout
')m4exit(`77')')dnl
sysval
(i.e. it prints out 1)
Note that there is a patch for the 'include' error but it is labeled as a 'gitpatch' and so won't be applied by default. This is because it is a .texi file and would require makeinfo (and therefore perl) to be able to build. Also - the 'right' fix is probably to either make m4 smarter and ignore the EDCxxxx message or have LE suppress it.
i think this one makes sense to put to the side for now until we get 'bash' built (since bash seems wrong here too) and perhaps it is a related issue (it's also an error path - trying to write to a redirected stream that has been closed)
I am not sure z/OS is wrong here - I think zsh is (and I get different results on my Mac in different shells)
On z/OS I get:
echo | cat >&-
but on Mac I get:
echo | cat >&-
cat: stdout: Bad file descriptor
I am going to try setting the shell for syscmd to be bash instead of /bin/sh and see if that fixes the problem (for dev build only)