1

I'm testing the portability of some stuff I'm writing to BSD. It's working on Linux, FreeBSD, OpenBSD. It isn't working on NetBSD.

The following is on a fresh VM installation I've made just for the purpose of testing this. I've traced the issue to

NetBSD$ uname -a
NetBSD NetBSD.local 9.1 NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

NetBSD$ cat /etc/shells                                                                                 
#       $NetBSD: shells,v 1.3 1996/12/29 03:23:07 mrg Exp $
#
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/sh
/bin/csh
/bin/ksh
/usr/pkg/bin/zsh
/usr/pkg/bin/bash

NetBSD$ for s in /bin/sh /bin/csh /bin/ksh /usr/pkg/bin/zsh /usr/pkg/bin/bash ; do echo $s; $s -c "echo OK" ; done
/bin/sh
/bin/csh
OK
/bin/ksh
/usr/pkg/bin/zsh
OK
/usr/pkg/bin/bash
OK
NetBSD$ su -
Password:
NetBSD# for s in /bin/sh /bin/csh /bin/ksh /usr/pkg/bin/zsh /usr/pkg/bin/bash ; do echo $s; $s -c "echo OK" ; done
/bin/sh
OK
/bin/csh
OK
/bin/ksh
OK
/usr/pkg/bin/zsh
OK
/usr/pkg/bin/bash
OK

Why doesn't sh -c "echo OK" and ksh -c "echo OK" work when I'm a non-root user, and why do they work when I'm root?

Other shells (csh, zsh, bash) work correctly, as shown above.

Improve this question
4
  • I can't reproduce this on an identical setup. Does sh -c "echo OK" not print anything if you give that command by itself, or is it only when it's part of your loop?
    – Kusalananda ♦
    Nov 22, 2020 at 16:46
  • Do you have SHA1 (/bin/sh) = f3d8c4ba3aec3baefa2e5758e628694afc190b85 and SHA1 (/bin/ksh) = b0835284c64fefceac9d96b34e8a482473716ec5? (use the sha1 command on the shell executables).
    – Kusalananda ♦
    Nov 22, 2020 at 17:08
  • @Kusalananda, thanks for the hashes and confirmation it worked for you. That pushed me to second guess my assumptions and I found the issue.
    – AProgrammer
    Nov 22, 2020 at 20:38
  • Thanks for posting an answer but since this comes down to a change you had made to your system, I am closing this as not reproducible because it is unlikely to help future users.
    – terdon ♦
    Nov 23, 2020 at 9:20

1 Answer 1

Reset to default
0

As Kusalananda's hashes matched mine and they hadn't the issue I dug further in my setup. My dotfiles are common between the OS variants and I don't have the issue there, but NetBSD sh and ksh behaves differently than other shells I've access and the issue was in my dotfiles.

I'm defining ENV so that I can define useful functions for interactive shells. I'm calling exit if the shell isn't interactive, I don't remember why as non csh shells don't source anything when non interactive. Well not all of them: NetBSD's sh and ksh are. And not only they are the only Bourne shell I've tested with that behaviour, they are also the only one which exit the shell on that exit, the other shells (tested with -ic) just stop processing the file and execute the command passed to -c.

Improve this answer
1
  • You're definitely not using ENV in a Ksh or POSIX compatible way! The exit command terminates the shell -- you just want to avoid sourcing the contents of your script, and the recommended way to do that is to wrap the contents in a conditional if statement with a test for when you want to evaluate the content. There's a fancier way to avoid the ENV file for true Ksh (and compatible), but it has some potential security risks.
    – Greg A. Woods
    Nov 24, 2020 at 1:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.