On Tue, Mar 12, 2024 at 8:16 AM Robert Elz <k...@munnari.oz.au> wrote:
> 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 '$$'. > > Uhm... I think you forgot to look at the actual code in the Makefile here. Every '$' is written as a '$$', exactly as you say it should. > > 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 > >
