completely silent startup, for use when scripting

[SethTisue]

sbt always prints these lines when it starts:

[info] Loading global plugins from /Users/tisue/.sbt/plugins
[info] Loading project definition from /Users/tisue/nl.headless/project

Is there a way to make it not? It messes up trying to pipe the output of commands around in the Unix shell.

this was requested on the mailing list https://groups.google.com/d/msg/simple-build-tool/VZFLPc-TWPw/2B6jx5Y_JF0J and at the time @harrah suggested opening a ticket, but I couldn't find one

related: #316, which was about overall levels of noisiness. this ticket is about being able to reduce noise all the way to zero when desired.

[harrah]

The part about configuring logging is included in #806 (might not be obvious, but it is).

There was a good point a while ago on the mailing list about sending logging to stderr, which I think would be the best fix for this.

[harrah]

The post was https://groups.google.com/d/topic/simple-build-tool/6LkVE8MVc78/discussion

[copumpkin]

If github supported voting, I'd vote for this one :)

[harrah]

@copumpkin the approach, the outcome, both?

[copumpkin]

The outcome, mostly. Separating stderr and stdout is also useful for other reasons, of course. Not sure whether this was implied in the thread, but it also seems helpful for warn/error messages to go to stderr and everything else to go to stdout.

[harrah]

The thread indicated all logging should go to stderr, with the preemptive point that stderr is something of a misnomer and isn't just for errors.

[SethTisue]

fwiw, I'd certainly be much happier if the stdout/stderr distinction were made, but some part of me would still want the option to set the loglevel at startup from the command line, so that irrelevant output never arises in the first place, on either stream. it's the unix way.

printing dull stuff to stderr causes the user to either visually/mentally tune out the chatter, or forcibly tune it out by redirecting stderr to /dev/null, and either way the result is that when one day sbt does have something different or important to say, they're likely to miss it.

[harrah]

The startup part is covered by the other issue. I've commented there so you believe me this time.

All logging-warnings, errors, info- would go to stderr. It isn't just errors or just info. So, you'd only tune it out if you were redirecting stderr so you don't see it. And if you do that, you probably meant to do it. I don't think it would change much for people using it normally/interactively.

[SethTisue]

loud & clear this time, thanks :-)

[Blaisorblade]

All logging-warnings, errors, info- would go to stderr. It isn't just errors or just info. So, you'd only tune it out if you were redirecting stderr so you don't see it. And if you do that, you probably meant to do it. I don't think it would change much for people using it normally/interactively.

Redirecting stderr to /dev/null sounds like a bad idea in 99% of cases. But IIUC, the "seeing only errors" use case — the one I'd prefer for continuous integration — would be supported through the other issue (#806), which is fine. But please correct my understanding if wrong.

[fommil]

the more annoying lines on startup are all the resolving lines, which really pollute CI runs. Putting this in the project's build config seems to silence Ivy a little bit, but putting it in the meta project (i.e. project/project/stfu.sbt) appears to be ignored.

    ivyLoggingLevel := UpdateLogging.Quiet

[ritschwumm]

this reminds me of a related problem:
when i call sbt 'show someSetting' from a script, the output is always prefixed with [info].
i can remove that with sed, but there might be a better way. ideas, anyone?

[ms-ati]

@jsuereth is there a plan for this now? It's one of those things (think we discussed at an NEScala event) that still makes SBT just unfriendly to scripting?

[SethTisue]

relevant: https://github.com/cb372/sbt-write-output-to-file

[frgomes]

I'd like to suggest that logging messages and all other informational messages are redirected to stderr, not stdout. The main reason lies behind the ability of writing Scala Scripts, which would send useful output to stdout.

[willis7]

Not sure im clear on the fix here. I have a CI build that could really use the output from sbt 'show version' but the output is making this annoying:

[info] Loading project definition from /Users/sion/Code/ons/sbt-scala-defaults/project
[info] Set current project to sbt-scala-defaults (in build file:/Users/sion/Code/ons/sbt-scala-defaults/)
[info] 0.1-SNAPSHOT

I'm using sbt 0.13.13. Should I be using a newer version of sbt?

[SethTisue]

@willis7 yes, 0.13.13 is quite old. please try 0.13.17 or, even better since the 0.13.x series is in maintenance mode these days, try 1.1.6

[SethTisue]

@willis7 see also #3091

[willis7]

@SethTisue sorry to labour this one. I've tried a few things now; upgrade to 0.13.17 (any higher and I get breaks I'm not qualified enough to fix) and read the issue you linked, but i still get:

$ sbt 'show version'
[info] Loading project definition from /Users/sion/Code/ons/sbt-scala-defaults/project
[info] Set current project to sbt-scala-defaults (in build file:/Users/sion/Code/ons/sbt-scala-defaults/)
[info] 0.1-SNAPSHOT

I've tried adding --warn etc. but still not getting just 0.1-SNAPSHOT

[SethTisue]

@willis7 I'm not able to reproduce the problem on either 0.13.17 or 1.1.6:

1.1.6:

% mkdir sbt-840 
% cd sbt-840
% sbt -warn 'show version'
%

0.13.17:

% rm -rf sbt-840
% mkdir sbt-840
% cd sbt-840
% mkdir project
% echo "sbt.version=0.13.17" > project/build.properties
% sbt -warn 'show version'                             
%

the show prints nothing in this scenario since show only prints at info level or higher, but that's a separate question unrelated to this ticket.

[willis7]

@SethTisue , what do you get if you remove the --warn as per my example?

[SethTisue]

@willis7 without -warn I get info-level logging, and that’s normal and expected. info-level logging is the default in sbt.

[willis7]

Its bizzare to me that I call a task asking for the version, and I get loads of unwanted logging information. It makes the task useless for any scripting tasks (unless I pipe to an elaborate squence of cmd tools). This is what I want:

$ sbt 'show version'
0.1-SNAPSHOT

Why does sbt make this so difficult?

[dwijnand]

Because it's built with its interactive shell as the primary use.

I'm not sure (at this time) how we might change sbt such that sbt 'show version' is nicely consumable, without impacting the rest of sbt, but if you have any ideas we'd be interested to hear them.

However, let's do so in a new issue, instead of necro-ing this one (we can always link to either the original request here and/or your recent comments).

[SethTisue]

print (or export) instead of show is often wanted here

it's also often desirable to add -batch (a synonym for < /dev/null), which turns off supershell and prevents sbt from ever presenting any kind of interactive prompt whatsoever (e.g. if build.sbt doesn't compile)

so a typical full invocation in a script is:

sbt -batch -error 'print version'