Open l29ah opened 7 years ago
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?
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
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. :-/
9d99a308bc59d1efb72c19535eace818cb4e51c9
Why don't you use the usual shell "to-fd" redirection like
echo foo >&1
?