11

I like to use set -x in scripts to show what's going on, especially if the script is going to run in a CI/CD pipeline and I might need to debug some failure post-hoc.

One annoyance with doing this is that if I want to echo some text to the user (e.g., a status message or "I'm starting to do $X") then that message gets output twice - once for the echo command itself being echoed, and then once as the output of that echo command.

What's a good way to make this nicer? One solution is this:

set -x

... bunch of normal commands that get echoed

(

Temporarily don't echo, so we don't double-echo

set +x echo "Here is my status message" )

... rest of commands get echoed again

But the two problems with that are

  1. That's a lot of machinery to write every time I want to tell the user something, and it's "non-obvious" enough that it probably requires the comment every time
  2. It echoes the set +x too, which is undesirable.

Is there another option that works well?

Something like Make's feature of prepending an @ to suppress echoing would be great, but I've not been able to find such a feature in Bash.

  • 1
    @ArkadiuszDrabczyk Converting it to a function doesn't even help with 1., because you have to call that function with the message as an argument, and that will be echoed. – Ken Williams Nov 16 '22 at 19:50
  • It helps with 1 because you don't have to disable tracing explicitly before each log – Arkadiusz Drabczyk Nov 16 '22 at 20:58
  • Don't use Bash then. – Marco Nov 17 '22 at 04:04
  • @ArkadiuszDrabczyk The point of disabling tracing was to not get the message printed twice. Using a function is as useful as using echo directly. – JoL Nov 17 '22 at 11:20
  • set -x is a debugging tool, not something intended to build nice text interfaces. – chepner Nov 17 '22 at 16:36
  • @chepner if there's a better technique to show the user what's happening as it's happening, I'm interested to hear it. – Ken Williams Nov 17 '22 at 23:06
  • It doesn't make sense to bend the mechanics of set -x just because you don't want your echos printed twice. – Marco Nov 18 '22 at 07:49
  • Choose the right tool for the job, if bash doesn't work for you, choose a different language. Nowadays there are not a lot of excuses left for not doing that. – Marco Nov 18 '22 at 07:51
  • 1
    Bash is fine for simple scripts, as soon as it gets complex, it's better to use a higher level language. I don't (seriously) get why so many people insist on doing everything in bash - it's stupid. – Marco Nov 18 '22 at 07:52
  • I think in many cases, complex Bash scripts started out simple and took on more and more features until they became complex. I've got one bash monstrosity that's thousands of lines of code split over two dozen or so files, but started out as just a couple dozen lines. Nobody's got time to rewrite the thing as long as it keeps working; I've been using it for five years, and it's more reliable than some of the fancy-shmancy things our tooling team has thrown at us. – A. R. Nov 18 '22 at 13:08
  • @AndrewRay Well that's very unfortunate. The person in charge should've made the switch to a higher language when it was still manageable. I don't mean to judge, it's a fast moving world and sometimes, we just want to get stuff done in the moment. However, I don't think it's right to support questionable questions (heh) like this one. The positive (it seems) reception only validates the idea of "let's just keep using bash and use some hack to get around X". Personally, I think the most upvoted answer here really is an abomination. There's an idiom "XY Problem", why not apply it here? – Marco Nov 18 '22 at 19:26
  • There is too much discussion and opinionating in these comments, please move to chat if you would like to continue. I'm quite happy with the answer I accepted - when asking the question I was doubtful that any such solution was even possible. Thank you. – Ken Williams Nov 18 '22 at 22:07