[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 May 2024 11:27:33 -0400
From: Rich Felker <dalias@...c.org>
To: Leah Neukirchen <leah@...u.org>
Cc: Collin Funk <collin.funk1@...il.com>, musl@...ts.openwall.com
Subject: Re: getusershell should ignore comments and empty lines.
On Thu, May 23, 2024 at 10:47:44AM -0400, Rich Felker wrote:
> On Thu, May 23, 2024 at 03:45:10PM +0200, Leah Neukirchen wrote:
> > Rich Felker <dalias@...c.org> writes:
> >
> > > It says:
> > >
> > > "A hash mark (``#'') indicates the beginning of a comment;
> > > subsequent characters up to the end of the line are not
> > > interpreted by the routines which search the file."
> > >
> > > This isn't very clear whether # is only a comment on the beginning of
> > > a line (after potential whitespace?) or whether # appearing in a line
> > > with a shell pathname is a comment or part of the pathname. If it's a
> > > comment, it's not clear if whitespace before it is part of the shell
> > > pathname -- e.g. does "/bin/sh # best shell" define "/bin/sh" or
> > > "/bin/sh " as the shell pathname?
> > >
> > > It sounds like nobody ever thought about whitespace, quoting, or
> > > rigorous comment syntax here...
> >
> > True:
> >
> > OpenBSD drops the rest of the line with "#" and ignores lines not
> > starting with a "/".
> >
> > glibc drops the rest of the line with "#", elides spaces after the
> > entry, and skips everything before the first "/" (quite bold).
> >
> > pam_shells skips all lines that don't start with a "/" and doesn't
> > handle "#" specially.
> >
> > gnome-terminal just tries to find one line that matches exactly the
> > the shell
> >
> > util-linux skips lines from getusershell that start with "#".
> > Likewise "seunshare".
>
> In general, musl policy is to support at most what's consistent
> between historical implementations.
>
> It seems like they all ignore lines that start with a '#'. They might
> (not clear from the above) also ignore blank lines.
>
> The minimal change both to avoid clashing with vaguely reasonable
> things user might want to put there (and violating least surprise),
> and to support the common behavior, seems to be just looping as long
> as the line is empty or starts with #.
Something like this?
Rich
View attachment "usershell.diff" of type "text/plain" (497 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
