Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: rbowman Newsgroups: comp.os.linux.misc Subject: Re: What programs do you make sure are installed on a new Linux Date: 17 Nov 2024 18:07:38 GMT Lines: 14 Message-ID: References: <8db593ab-0793-2b31-ebc3-922a5d2fc241@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net 3i37F6bTV/popFRO10YTbgwlHdU6JpVcYxdYiC3PRCO1cc4OVA Cancel-Lock: sha1:o5+z0zrFsetz5A7BDQJc/YnAoj4= sha256:EunmuCR4gs/257jlJWbsS3JAUjumRcr4qnMtla5tqIk= User-Agent: Pan/0.149 (Bellevue; 4c157ba) Xref: csiph.com comp.os.linux.misc:61040 On Sun, 17 Nov 2024 17:17:37 GMT, Charlie Gibbs wrote: > Horses for courses. Never underestimate the value of a few printf()s > sprinkled here and there (or log file writes if you're really headless). > I'm still a fan of makefiles. I'm a dinosaur so my preferred technique is either printf or log files. For production code I've sometimes created a sequence of log statements that can be turned on with a flag that are a narrative of what's going on. My goal is a support person can read the file and see where the problem occurs. Often it is a configuration issue they can fix. The nice part is the technique can be used with any language and is effective where a debugger isn't available.