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] |