Is there any way to turn off the fancy color output that hab generates by default? I’ve been poking through my logs, and in preparing them for some post-processing I discovered that stripping out the color code information I was able to reduce my log volume by a little over 20%. Color is neat and all for development, but I don’t really need it for things that have been deployed.
Poking around in the docs, here, and with the cli help hasn’t turned up anything.
oh, and for anyone who is interested, I did this quicky sed invocation to do it:
cat api_logs_2018-08-28.txt | sed 's/\x1b\[[0-9;]*m//g' | sed -e 'y/\t/\n/' > api_logs_2018-08-28.txt.cleaned
The first sed is the one that strips the color codes, the second converts tabs to newlines. You likely don’t need the second one, unless you are using awslogs to pull your logs out of cloudwatch logs like I am.
We actually have a couple ways you can do this. The first I think is an envvar HAB_NOCOLORING which works specifically with the build program. The other is the --no-color flag when a supervisor is started! Both of these are in the docs so I’m a little worried that you weren’t able to find them with the search bar - they seem to be indexed appropriately so I’m not sure what’s up there. Hope this helps!
Thanks!
I do see the --no-color flag, but I was wondering more about how to make services I package behave this way “out of the box”. Sorry, I wrote my initial post poorly. Reading it again it’s not at all clear what I was looking for.
In terms of implementation, how would I bake this into my build process if I want to disable the color output of the supervisor on my packaged apps by default? It looks like I could pass the argument to docker and it would be passed in to the supervisor invocation by init, but that would only work as a post-build config step and only if I package into docker.
Or, more generally, how can I influence how the supervisor starts by default (with envvars or cli options) from within my plan?
It looks like setting that envvar in do_setup_environment might do it?
Hmm that’s a good question. I think you could definitely attempt setting the envvar in do_setup_environment but I think that envvar only has an effect on the build program itself not the supervisor. Are you deploying into kubernetes today or do you bootstrap VMs and use systemD? Basically whatever you’re using to provision supervisors is what should set the --no-color flag. Right now plans have no control themselves over the supervisor’s behavior so the other option is if your service itself may have some runtime flags you could set in the runhook which would solve the issue of color in the logs that is generated by your service itself. That being said, I think I at one point had a conversation with @bixu or @smartb-pair about this a long time ago in a galaxy far away. I’ve tagged them just in case I am remembering correctly 
OK, I’ll probably just pass the --no-color as a container cmd option for now since I’m living in docker world. It appears that should get passed in to the supervisor startup via the init.sh.
I don’t know how often this comes up, but having a standard way to poke at this sort of thing from within a plan seems like it would be handy.
I think having this in a plan might be a misstep that would break the encapsulation of build and runtime. You could totally add it as an option to the docker exporter though.
It’d probably require a new flag in here and some plumbing to get it here
Yeah, totally could be bad. It felt bad to me, but I also couldn’t think of a better way to make changes to default sup behavior. Making it an option in the exporter makes sense though. Thanks for the pointers to the code.