Hi Bruno,

On 5/20/24 3:28 AM, Bruno Haible wrote:
>> It looks like the current code wants drive-prefixes accepted, i.e.
>> 'c:/ugly/windows/stuff'.
> 
> ?? I don't see such code in gnulib/lib/getusershell.c.

It is defined in the 'ADDITIONAL_DEFAULT_SHELLS' macro [1]:


#if ! defined ADDITIONAL_DEFAULT_SHELLS && defined __MSDOS__
# define ADDITIONAL_DEFAULT_SHELLS \
  "c:/dos/command.com", "c:/windows/command.com", "c:/command.com",
#else
# define ADDITIONAL_DEFAULT_SHELLS /* empty */
#endif

/* List of shells to use if the shells file is missing. */
static char const* const default_shells[] =
{
  ADDITIONAL_DEFAULT_SHELLS
  "/bin/sh", "/bin/csh", "/usr/bin/sh", "/usr/bin/csh", NULL
};


>> That sort of breaks the behavior of glibc and BSD where:
>>
>>      input -> getusershell () output
>>      'bin/bash' -> '/bash'
> 
> ?? The code in gnulib/lib/getusershell.c does not test for a '/'.

I probably explained it poorly, sorry. Perhaps the important section
of code in glibc will help explain [2].

I was trying to point out that glibc and BSD will only return absolute
file names. Since they do not target Windows that means just looking
for a '/'.

Here is a test program:

=====================
#define _GNU_SOURCE 1
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int
main (void)
{
  char *p;
  while ((p = getusershell ()))
    printf ("%s\n", p);
  return 0;
}
=====================

My /etc/shells:

=====================

this-part-gets-removed/this-doesn't/bash
/bin/sh
=====================

And then the program output:

$ uname -o
GNU/Linux
$ ./a.out 
/this-doesn't/bash
/bin/sh

The file format isn't very well defined, in my opinion [3]. I think
the common assumption is that administrators put sane absolute file
names one-per-line. Like this:

/bin/bash
/bin/sh
/bin/ksh
/usr/bin/csh

The other patch I sent would behave similarly enough to glibc and BSD
in my opinion while allowing for drive prefixes on Windows and spaces
since I think they are common there.

The removal of the first non-absolute part is strange in my opinion.

Collin

[1] https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/getusershell.c#n48
[2] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getusershell.c;h=4221095dca743dfa5067637f1aad4651bd5cf279;hb=2be3352f0b1ebaa39596393fffe1062275186669#l130
[3] 
https://man.freebsd.org/cgi/man.cgi?query=shells&sektion=5&apropos=0&manpath=FreeBSD+14.0-RELEASE+and+Ports

Reply via email to