by I have encountered a peculiar bug in /bin/sh on Ultrix 4.0 and Ultrix
3.1. To recreate it, do the following:
echo "echo foo ran" | foo
chmod +x foo
sh -c "\/\f\o\o"
In the final line, I assume that foo is in the root directory. This
is probably false. You should put in the directory you are working
in, quoting each character with a backslash. For example, if you are
in /usr/ian:
sh -c "\/\u\s\r\/\i\a\n\/\f\o\o"
On Ultrix 4.0 I get something like
/bin/sh: 8: cannot open
The actual character which appears instead of '8' varies.
On Ultrix 3.1 I get
/bin/sh: /usr/ian/foo: not found
In both cases it should print
foo ran
On both systems this works fine with sh5. It also works on SCO 3.2.2.
If I don't quote some of the characters, it sometimes works. I've
been unable to find any consistency to it.
I'm doing this extensive quoting in order to safely run a program with
arguments using /bin/sh without having the arguments expanded by the
shell. Specifically, this is for a UUCP program. uuxqt tries to run
the program using execve. If that fails with ENOEXEC, it quotes each
character in the execution request (as shown) and passes it to
/bin/sh. If uuxqt does not quote all special characters, various
sorts of chicanery become possible. Quoting every character is not,
of course, necessary, but it's convenient and in any case I don't know
when I will run into this problem.
What I'd like to know is:
1) Is this a known bug?
2) Is it specific to Ultrix, or does it happen on other BSD
derivatives?
3) How do I work around it?
This site does not get comp.unix.shell, so if you respond only to that
newsgroup please also mail me a copy.
Many thanks.
--
First person to identify this quote wins a free e-mail message:
``Every so many years he went to England to visit--judging by the
photographs he showed us--a sundial and some oak trees.''