paths.h and similar constants, internal usage?

paths.h and similar constants, internal usage?

[u-igbb]

Hello,

I noticed that musl defines certain constants but does not use them
even when it could. I find if better in the long run to have
a single definition of a string instead of multiple ones, for
various reasons.

Would it be suitable for upstream to make use of the available symbolic
constants in the following cases where explicit strings are being used
instead:

-----------------------------------------------------------------------------
./include/paths.h:#define       _PATH_DEFPATH "/usr/local/bin:/bin:/usr/bin"
./src/process/execvp.c: if (!path) path = "/usr/local/bin:/bin:/usr/bin";
-----------------------------------------------------------------------------
./include/paths.h:#define       _PATH_BSHELL    "/bin/sh"
./src/process/system.c: ret = posix_spawn(&pid, "/bin/sh", 0, &attr,
./src/stdio/popen.c:                    if (!(e = posix_spawn(&pid, "/bin/sh", &fa, 0,
./src/misc/wordexp.c:           execl("/bin/sh", "sh", "-c",
-----------------------------------------------------------------------
./include/paths.h:#define       _PATH_DEVNULL   "/dev/null"
./src/legacy/daemon.c:          if ((fd = open("/dev/null", O_RDWR)) < 0) return -1;
./src/env/__init_security.c:            if (__syscall(SYS_open, "/dev/null", O_RDWR|O_LARGEFILE)<0)
-----------------------------------------------------------------------
./include/syslog.h:#define _PATH_LOG "/dev/log"
./src/misc/syslog.c:    "/dev/log"
-----------------------------------------------------------------------
./include/resolv.h:#define _PATH_RESCONF        "/etc/resolv.conf"
./src/network/__dns.c:  f = __fopen_rb_ca("/etc/resolv.conf", &_f, _buf, sizeof _buf);
./src/network/getaddrinfo.c:    f = __fopen_rb_ca("/etc/resolv.conf", &_f, _buf, sizeof _buf);
-----------------------------------------------------------------------
./include/paths.h:#define       _PATH_SHADOW    "/etc/shadow"
./include/shadow.h:#define      SHADOW "/etc/shadow"
./src/passwd/getspnam_r.c:              f = fopen("/etc/shadow", "rbe");
-----------------------------------------------------------------------
./include/paths.h:#define       _PATH_SHELLS    "/etc/shells"
./src/legacy/getusershell.c:    if (!f) f = fopen("/etc/shells", "rbe");
-----------------------------------------------------------------------
./include/paths.h:#define       _PATH_TTY       "/dev/tty"
./src/legacy/getpass.c: if ((fd = open("/dev/tty", O_RDONLY|O_NOCTTY)) < 0) fd = 0;
./src/unistd/ctermid.c: fd = open("/dev/tty", O_WRONLY | O_NOCTTY | O_CLOEXEC);
-----------------------------------------------------------------------

If yes, then I can try to prepare a patch.

Regards,
Rune

Re: paths.h and similar constants, internal usage?

[Rich Felker]

On Sat, Mar 29, 2014 at 08:38:57AM +0000, u-igbb@aetey.se wrote:
> Hello,
> 
> I noticed that musl defines certain constants but does not use them
> even when it could. I find if better in the long run to have
> a single definition of a string instead of multiple ones, for
> various reasons.
> 
> Would it be suitable for upstream to make use of the available symbolic
> constants in the following cases where explicit strings are being used
> instead:

paths.h is just there for making some bad legacy apps happy. It's not
a system we want to use.

As for changing these paths, it's of course something you can do by
changing the source and I can't keep you from doing it, but it's also
not something I have an interest in making easy/automated. For the
most part, changing them has no purpose except making it so your
static binaries don't work on normal systems. musl aims to make
minimal assumptions about pathnames, and those which it does assume
are either required by standards, de facto requirements for
compatibility with anything (e.g. the shell has to be at /bin/sh for
scripts to work anyway), or historically so universal that any system
can be expected to have them.

Anyway, if you have specific requirements you're trying to find a
solution to, please let us know what you're doing. For any request
like this, a strong motivation is needed.

Rich

Re: paths.h and similar constants, internal usage?

[u-igbb]

Hello Rich,

On Sat, Mar 29, 2014 at 01:19:46PM -0400, Rich Felker wrote:
> paths.h is just there for making some bad legacy apps happy. It's not
> a system we want to use.
 [... skipping the more detailed clarification ...]

Ok, I see you want to keep it separate (and possibly even be able
to lie to the legacy applications when you find it fit).

> Anyway, if you have specific requirements you're trying to find a
> solution to, please let us know what you're doing. For any request
> like this, a strong motivation is needed.

This was not a request, but mostly an offer. I felt that explicit
synchronization of identical strings might help consistency.
Not like I need this for my own purposes.

As to the contrary you want to keep these parts as far apart from each
other as possible, there is of course no sense in pursuing a non-goal. :)

Rune