This whole discussuon has been a total mess. First the original message didn't give nearly enough info. That might have been in the attachment, but no-one should be expecting people to do any needless work when you're asking for (free) assistance - if you want help you need to make it as easy as possible for people to do that.
Second, a very common issue with people having problems, is when they have a problem to solve, they work out how they think they should do that, and then have difficulty making one of the steps work. At that point they ask how to do that thing, which might sometimes be very complex, even impossible. If the initial problem had been stated, along with the solution proposed, leading to the issue that's hard, then instead of (perhaps) wasting needless time dreaming up possible solutions to difficult problems, someone might just point out a much simpler method to solve the original problem, making finding a solution to the difficult issue moot. Second, the replies here have mostly been hopeless, with just a couple addressing real issues. Many of the initial replies totally missed that the OP said that the bash script in 'one' worked, and there was this long thread suggesting other ways to do it. Waste if everyone's time (even if the advice not to use SECONDS was probably useful). There is however no blanket rule that vars in upper case are reserved for the shell - posix contains a list of var names scripts should avoid using (unless they want some particular feature supported by a particular shell they are using - SECONDS & RANDOM are on that list). Anything else is (or should be) OK to use. The issue with 'one' was that the same code did not work on the command line, or in a makefile. Chet explained the command line problem: Date: Mon, 11 Mar 2024 17:25:57 -0400 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <322e10a6-3808-49be-aa9d-a1d367a90...@case.edu> | OK, here's the longer answer. When the shell is interactive, and job | control is enabled, the shell prints job completion notifications to | stdout at command boundaries. which is, IMO, yet another bogus bash misfeature. That should happen, with the effect described, but only when PS1 is about to be printed - precisely so commands like the one described will work. Sigh. There aren't many complaints about this misfeature of bash, as almost no-one writes interactive command lines where it makes a difference. That doesn't mean they should not be able to. For the problem using make, it was suggested to explicity set the SHELL to use in the makefile, which is good advice when using shell specific features, as is being done here. But the real problem is almost certainly that the Makefile is attempting to pass scripts containing '$' chars to the shell. '$' is interpreted by make, to send a '$' to the shell, it must be written as '$$'. For problem 'two', Greg (I think it was) diagnosed the issue with var expansions, and field splitting - but if that was unknown to the OP then that OP has no business attempting to write any shell script (with any kind of variable) - get an introductory shell programming text and learn how it works - at least the basics. Don't just guess or attempt to copy other scripts, you'll fail. kre