linuxcnc doesn't like being run from `su` and friends: /dev/fd/1: Permission denied

[l29ah]

9d99a308bc59d1efb72c19535eace818cb4e51c9

$ linuxcnc -v
/usr/bin/linuxcnc: line 123: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 222: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 232: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 233: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 234: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 235: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 236: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 237: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 238: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 239: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 240: /dev/fd/1: Permission denied
/usr/bin/linuxcnc: line 241: /dev/fd/1: Permission denied
LINUXCNC - 2.8.0~pre1

Why don't you use the usual shell "to-fd" redirection like echo foo >&1?

[SebKuzminsky]

I'm not able to reproduce this problem. I tried a couple of old 2.7 versions and the current tip of master (9d99a308b), all installed by debs from www.linuxcnc.org or from the buildbot, on Wheezy/i386/rtai and Stretch/rt-preempt/amd64. I tried running "linuxcnc -v", "sudo linuxcnc -v", and "sudo su -" followed by "linuxcnc -v", and all of them started the config picker without printing any "Permission denied" errors.

What platform (distro, kernel version, architecture) did you run your test on?

Did you build linuxcnc yourself or did you install our debian packages?

What was the sequence of commands that led to this output?

[l29ah]

On Tue, Sep 19, 2017 at 08:01:54PM +0000, Sebastian Kuzminsky wrote:

I'm not able to reproduce this problem. I tried a couple of old 2.7 versions and the current tip of master (9d99a308b), all installed by debs from www.linuxcnc.org or from the buildbot, on Wheezy/i386/rtai and Stretch/rt-preempt/amd64. I tried running "linuxcnc -v", "sudo linuxcnc -v", and "sudo su -" followed by "linuxcnc -v", and all of them started the config picker without printing any "Permission denied" errors.

What platform (distro, kernel version, architecture) did you run your test on? Did you build linuxcnc yourself or did you install our debian packages?

Gentoo, built from source.

What was the sequence of commands that led to this output?

I run su - in my terminal emulator to get into root. I then run su - <linuxcnc user>. Then linuxcnc -v tries to open the symlink to a pts file that belongs to the original user.

-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments

[jepler]

The script does that so that we can decide at runtime whether to show output on stdout/stderr, or to store it in files. Patches welcome, but we can't break existing functionality in the process.

Based on this text from bash(1), I'm surprised there's a problem:

       Bash handles several filenames specially when they are used in redirec‐
       tions, as described in the following table.  If the operating system on
       which bash is running provides these special files, bash will use them;
       otherwise it will emulate them internally with the  behavior  described
       below.

              /dev/fd/fd
                     If  fd  is  a valid integer, file descriptor fd is dupli‐
                     cated.
              /dev/stdin
                     File descriptor 0 is duplicated.
              /dev/stdout
                     File descriptor 1 is duplicated.
              /dev/stderr
                     File descriptor 2 is duplicated.
              /dev/tcp/host/port
                     If host is a valid hostname or Internet address, and port
                     is  an integer port number or service name, bash attempts
                     to open the corresponding TCP socket.
              /dev/udp/host/port
                     If host is a valid hostname or Internet address, and port
                     is  an integer port number or service name, bash attempts
                     to open the corresponding UDP socket.

       A failure to open or create a file causes the redirection to fail.

but I guess in this case /dev/fd exists, but the semantics are such that it's NOT actually like dup()ing the existing file descriptor. :-/