Yeah, I’m -1 on sending logs on stderr, that doesn’t seem to make any sense :)
Alexander: good catch on 1.x doing both. Paul et.al: can we retain that? Best Jan -- > On 09 Aug 2016, at 23:28, Alexander Shorin <[email protected]> wrote: > > I actually not sure what happens in stdout and do we really need that. > Good size of stderr is that it's the only source that can reveal > startup crashes, before couch_log will be initialized to write > anything to file. > -- > ,,,^..^,,, > > > On Wed, Aug 10, 2016 at 12:22 AM, Paul Davis > <[email protected]> wrote: >> Meh. Just create a stdout module that proxies calls to stderr (or vice >> versa) and then just make a config thing at the top. Should be as >> simple as I first thought that way. >> >> On Tue, Aug 9, 2016 at 4:22 PM, Paul Davis <[email protected]> >> wrote: >>> New logging also doesn't actually have stdout as an option but that'd >>> be a trivial change to make. Though the name of the writer could be >>> weird. >>> >>> On Tue, Aug 9, 2016 at 4:06 PM, Alexander Shorin <[email protected]> wrote: >>>> On Tue, Aug 9, 2016 at 10:00 PM, Jan Lehnardt <[email protected]> wrote: >>>>> I'd say we keep 1.x behaviour of logging to file by default with an >>>>> option to override to stdX for the envs that want that. >>>> >>>> Actually, 1.x behaviour is about to log both to stdout/stderr and file >>>> at the same time. Package maintainers actually just suppress >>>> stdout/stderr because we already have a file logging. Those options -o >>>> and -e about to redirect stdout/stderr to specific files, but this >>>> doesn't overrides file logging. >>>> >>>> -- >>>> ,,,^..^,,, -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
