This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi! I agree that this functionality is a useful addition. On Mon, 30 Jan 2012 23:12:29 -0200, Alexandre Oliva <aoliva@redhat.com> wrote: > On Jan 23, 2012, Roland McGrath <roland@hack.frob.com> wrote: > > > This seems generally sound to me. But I'd like to know if there is > > any existing precedent for an option letter and/or long option name > > for doing this in another GNU utility. > > I'm afraid I couldn't find examples of programs that offered this level > of flexibility, so I saught guidance in the GNU coding standards. > http://www.gnu.org/prep/standards/standards.html#Option-Table > > âforegroundâ > For server programs, run in the foreground; in other words, donât do > anything special to run the server in the background. > > âdebugâ > â-dâ in make and m4; â-tâ in Bison. > > There doesn't seem to be a standard short option for â--foregroundâ; > indeed, some non-GNU programs use -d to daemonize, whereas others use it > to enter debugging mode. I couldn't tell (by just looking at remote > docs) whether they changed behavior WRT syslog when they offered both > options. It's a bit of a mess already :-( Why do we need a short option at all? Aren't these mainly for saving a few keyboard hits in interactive shell use? Unless really established, I tend to prefer using long options in anything that's scripted; it's more clear to the reader, as you have just demonstrated (-d vs. -t, for example). > > Perhaps cleaner to have two bools. > > I've considered adding --[no-]syslog, but we don't really have 4 > different possibilities in the choice space. It doesn't make sense to > send output to std* if you daemonize: it's really 3-state. What about using an enum? > >> + fprintf (stderr, _("further output sent to syslog\n")); > > > What's the point of this message? > > It's just so that someone who runs the program in --foreground isn't > surprised by the absence of output when the program runs in foreground, > behavior that is new and unlike that of -d. I agree this message should go away. ``No message == all OK'' is the standard UNIX paradigm. If I were systemd, I would potentially consider seeing a daemon write to stderr as an indication for an error. > > It's not normal for daemon startup to print anything to stderr in my > > experience. > > This won't be printed in daemon mode, only in --foreground mode. GrÃÃe, Thomas
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |