Re: REQUEST - bash floating point math support

Le 14/06/2024 à 03:41, Martin D Kealey écrivait : On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote: Let's say, if var is in the form of a C floating-point literal, ${var@F} would expand it to the locale-dependent formatted number, for use as an argument to printf or for output directly. And

RE: set -a leads to truncated output from ps

Thanks Chet, Your explanation is crystal clear and shows how bash follows its documentation and vice versa. However, how many users of bash in the world could have this understanding of how set -a, checkwinsize and COLUMNS interact with each causing "PS" to change its behavior in mid-flight

Re: it, soRE: set -a leads to truncated output from ps

u can try shopt -u checkwinsize to disable that columns settings On Thu, Jun 13, 2024, 8:29 PM Alain BROSSARD via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > > You are correct, export COLUMNS does truncate, I had made the mistake > of replaying the previous execution of ps wh

Re: set -a leads to truncated output from ps

On Fri, Jun 14, 2024 at 07:28:41AM +, Alain BROSSARD wrote: > Honestly, I don't know where to go with this issue. Bash's behavior > should be consistent and easily understood in order to have reliable scripts. > Clearly this case doesn't respect this. > I would suggest to put LINES an

RE: set -a leads to truncated output from ps

Hi Greg, The original problem started with I added “echo $PATH | grep ….” Into a “site” configuration file source’d from our vendor’s scripts. So yes, this whole issue is present in scripts. It took me quite a while to figure out why our vendor’s scripts were now failing and on how to rep

Re: set -a leads to truncated output from ps

On Fri, Jun 14, 2024 at 11:36:19AM +, Alain BROSSARD wrote: > ps axww isn’t impacted, but the scripts use ‘ps ax’. Oh. Well then, that's the most obvious thing to fix.

Re: REQUEST - bash floating point math support

Great idea. On Fri, Jun 14, 2024 at 3:18 AM Léa Gris wrote: > > Le 14/06/2024 à 03:41, Martin D Kealey écrivait : > > On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote: > > > >> > >> Let's say, if var is in the form of a C floating-point literal, > >> ${var@F} would expand it to the locale-depe

Re: set -a leads to truncated output from ps

Date:Fri, 14 Jun 2024 07:28:41 + From:Alain BROSSARD Message-ID: Most of this looks to be solved, or solvable now, but I see no-one seems to have replied to this particular comment: | Add to this that it is extremely difficult to check whether -a is set | o

Re: set -a leads to truncated output from ps

2024年6月14日(金) 16:30 Alain BROSSARD : Even if the behavior of `set -a' is modified, your script (or the third-party script that you rely on?) is still broken when the user explicitly gives COLUMNS and LINES the export attribute, which is a *typical usage of those variables*. This should be a bug i

Re: REQUEST - bash floating point math support

2024年6月14日(金) 16:18 Léa Gris : > Another elegant option would be to expand the existing variables' i flag > to tell the variable is numeric rather than integer. > > Then have printf handle argument variables with the numeric flag as > using the LC_NUMERIC=C floating-point format with dot radix poin

Re: set -a leads to truncated output from ps

On Saturday, June 15, 2024, Koichi Murase wrote: > > Also, the behavior of the `ps' command honoring COLUMNS to format its > output is also an expected one. > The fact that programs giving precedence to COLUMNS over the terminal API are so common is an argument against exporting COLUMNS behind th