Hi Collin, > >> 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",
Inside '#if defined __MSDOS__' or '#if defined _WIN32' this is OK. I was worried there was explicit code to accept such prefixes on POSIX compatible platforms. Fortunately not. > 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 '/'. Ah, yes, the glibc implementation tests for a '/' somewhere in the loop. > ===================== > > 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. Yes, stripping off the first component of a relative file name is certainly not what anyone would expect. Your choice of dropping that string entirely is better, IMO. Your use of IS_ABSOLUTE_FILE_NAME is fine. Bruno
