csh: Permission denied
csh: Trying to start from "/var/log"
message.
This was caused by the
su -m uucp -c "uustat -a"
line being executed in a directory not readable by uucp. The login
shell implied by -m is of course root's shell, /bin/csh, which doesn't
like not being able to read the dir it is in, and thus the errors. By
temporarily cd'ing to /tmp the problem is fixed.
What is really needed, of course, is a way to tell su what shell you
want to use explicitly, especially for use in scripts where the
vagaries of which shell the login executing the script uses should not
be depended on. No such method exists. One should be added.
Indeed, it might also be nice to have a way of telling su to directly
execute a command with -c rather than using a shell to interpret the
command.
I cannot find any standards documents that specify su at the moment,
though. SuSv2 is silent on su(8).
host that's doing the filing (with a suitable comment for non-usual
cases), as suggested by Don Yuniskis in PR 14217 and lukem on tech-pkg.
Also closes PR's 13938, 14104.
- Garbage collect some cruft that doesn't apply to the ofppc port.
- Make our OFW-friendly alloc.c more like the libsa alloc.c
- Generally reduce some differences where we can between this
boot loader and the NetBSD/macppc boot loader.
- Use libsa's loadfile().
- Fix DDB symbol loading -- Add a magic number after the args string
so the kernel knows the symbols are there, provide both ssym and
esym, and make sure all these values are aligned to a 4-byte boundary.
- Add support for MS-DOS file systems.
- add _PATH_PASSWD_CONF to be consistent with almost all other _PATH_xxx_CONF
defines, and change from using _PATH_PASSWDCONF to the former. keep the
latter for compatibility, although arguably it could be removed because
it was never in a release and was only used in one file in the tree.
support to GDB ARM targets in general, and make corresponding changes to
NetBSD-specific code.
The first half of this has already been send to gdb-patches by Richard.
The second half is irrelevant to them since they don't yet have NetBSD/arm
support in their tree yet.