Re: REQUEST - bash floating point math support
On 6/5/24 2:59 AM, Léa Gris wrote: Le 05/06/2024 à 17:09, Koichi Murase écrivait : 2024年6月5日(水) 21:41 Zachary Santer : Bash could potentially detect floating point literals within arithmetic expansions and adjust the operations to use floating point math in that case. [...] ksh and zsh are already behaving in that way, and if Bash would support the floating-point arithmetic, Bash should follow their behavior. Bash isn't even consistent with the floating point data/input format when using printf '%f\n' "$float_string" as it depends on LC_NUMERIC locale. LC_MESSAGES=C LC_NUMERIC=fr_FR.UTF8 printf '%f\n' 3.1415 bash: printf: 3.1415: invalid number 3,00 Chet explained it is because Bash is following the POSIX norm and C printf rules. This is true. The printf(3) engine, which bash uses to display floating point numbers, uses the radix character from the LC_NUMERIC locale category. The arguments to printf(1) have to be converted to floating point format to pass to printf(3). strtod(3), which bash uses to perform this conversion, uses the radix character from LC_NUMERIC as well. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Echoing commands
Hi, I am running bash 5.2.15(3)-release (x86_64-pc-cygwin) on cygwin running on Windows 10. Bash lacks a proper way of echoing commands, which is present in other shells, even in ones which are much less powerful, like, e.g. Windows CMD. This is not the same as debugging, for which set -x is devoted. "set -x" makes the ensuing commands be printed, but prefixed with "+ ", which makes the result look ugly, not to mention that the following "set +x" is echoed too (there are hacks to suppress the "set +x" output, but they are just hacks). What is needed is something equivalent to the @echo on, @echo off of the old DOS CMD, that are not printed and that enable/disable echoing of commands without any debugging marks added (such as "+" of set -x). The solution could look like: set -o log cat tmp >tmp1# or any other command set -o nolog producing the output on the console cat tmp >tmp1 I would stress the importance of this: the purpose of scripts is to execute commands, informing the caller of what they execute, purged of all the builtins and other calculations the script does in order to come to the commands. Many solutions are posted in the internet, all of them are hacks with lots of edge cases that make them fail in presence of commands containing special characters, redirections, substitutions, etc. Thank you -Angelo Borsotti
Re: Echoing commands
On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote: > "set -x" makes the ensuing commands be printed, but prefixed > with "+ ", which makes the result look ugly, not to mention that > the following "set +x" is echoed too (there are hacks to suppress > the "set +x" output, but they are just hacks). If all you want is to remove the "+ ", you can simply set the PS4 variable to an empty string. > set -o log > cat tmp >tmp1# or any other command > set -o nolog > > producing the output on the console > >cat tmp >tmp1 If you want to retain redirections in the -x output, that's a whole different issue. There is currently no way to do that. Chet would have to implement something.
Re: Echoing commands
~ $ logf=$HOME/alog1 ; run1() { printf '%(%F+%T%z)T %s' -1 "$1" >>"$logf" ;
(( $# > 1 )) && printf \ %s "${@:2}" >>"$logf" ; "$@" ; >>"$logf" printf
\\n ; } ; run1 echo foo ; cat "$logf"
foo
2024-06-12+22:51:31+0200 echo foo
~ $
On Wed, Jun 12, 2024, 10:26 PM Greg Wooledge wrote:
> On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote:
> > "set -x" makes the ensuing commands be printed, but prefixed
> > with "+ ", which makes the result look ugly, not to mention that
> > the following "set +x" is echoed too (there are hacks to suppress
> > the "set +x" output, but they are just hacks).
>
> If all you want is to remove the "+ ", you can simply set the PS4
> variable to an empty string.
>
> > set -o log
> > cat tmp >tmp1# or any other command
> > set -o nolog
> >
> > producing the output on the console
> >
> >cat tmp >tmp1
>
> If you want to retain redirections in the -x output, that's a whole
> different issue. There is currently no way to do that. Chet would
> have to implement something.
>
>
Re: Echoing commands
~ $ args1() { printf %s\ "${@@K}" ; printf \\n ; } ; args1 echo foo ;
args1 echo two three 'echo' 'foo'
'echo' 'two' 'three'
~ $
On Wed, Jun 12, 2024, 10:52 PM alex xmb sw ratchev
wrote:
> ~ $ logf=$HOME/alog1 ; run1() { printf '%(%F+%T%z)T %s' -1 "$1" >>"$logf"
> ; (( $# > 1 )) && printf \ %s "${@:2}" >>"$logf" ; "$@" ; >>"$logf" printf
> \\n ; } ; run1 echo foo ; cat "$logf"
> foo
> 2024-06-12+22:51:31+0200 echo foo
> ~ $
>
> On Wed, Jun 12, 2024, 10:26 PM Greg Wooledge wrote:
>
>> On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote:
>> > "set -x" makes the ensuing commands be printed, but prefixed
>> > with "+ ", which makes the result look ugly, not to mention that
>> > the following "set +x" is echoed too (there are hacks to suppress
>> > the "set +x" output, but they are just hacks).
>>
>> If all you want is to remove the "+ ", you can simply set the PS4
>> variable to an empty string.
>>
>> > set -o log
>> > cat tmp >tmp1# or any other command
>> > set -o nolog
>> >
>> > producing the output on the console
>> >
>> >cat tmp >tmp1
>>
>> If you want to retain redirections in the -x output, that's a whole
>> different issue. There is currently no way to do that. Chet would
>> have to implement something.
>>
>>
Re: Echoing commands
there are two output lines , for the two cmds , sorry gmail problem
On Wed, Jun 12, 2024, 10:57 PM alex xmb sw ratchev
wrote:
> ~ $ args1() { printf %s\ "${@@K}" ; printf \\n ; } ; args1 echo foo ;
> args1 echo two three 'echo' 'foo'
> 'echo' 'two' 'three'
> ~ $
>
> On Wed, Jun 12, 2024, 10:52 PM alex xmb sw ratchev
> wrote:
>
>> ~ $ logf=$HOME/alog1 ; run1() { printf '%(%F+%T%z)T %s' -1 "$1" >>"$logf"
>> ; (( $# > 1 )) && printf \ %s "${@:2}" >>"$logf" ; "$@" ; >>"$logf" printf
>> \\n ; } ; run1 echo foo ; cat "$logf"
>> foo
>> 2024-06-12+22:51:31+0200 echo foo
>> ~ $
>>
>> On Wed, Jun 12, 2024, 10:26 PM Greg Wooledge wrote:
>>
>>> On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote:
>>> > "set -x" makes the ensuing commands be printed, but prefixed
>>> > with "+ ", which makes the result look ugly, not to mention that
>>> > the following "set +x" is echoed too (there are hacks to suppress
>>> > the "set +x" output, but they are just hacks).
>>>
>>> If all you want is to remove the "+ ", you can simply set the PS4
>>> variable to an empty string.
>>>
>>> > set -o log
>>> > cat tmp >tmp1# or any other command
>>> > set -o nolog
>>> >
>>> > producing the output on the console
>>> >
>>> >cat tmp >tmp1
>>>
>>> If you want to retain redirections in the -x output, that's a whole
>>> different issue. There is currently no way to do that. Chet would
>>> have to implement something.
>>>
>>>
Re: Echoing commands
args1() { printf %s\ "${@@K}" ; printf \\n ; } ; args1 echo foo ; args1
echo two three
On Wed, Jun 12, 2024, 10:58 PM alex xmb sw ratchev
wrote:
> there are two output lines , for the two cmds , sorry gmail problem
>
> On Wed, Jun 12, 2024, 10:57 PM alex xmb sw ratchev
> wrote:
>
>> ~ $ args1() { printf %s\ "${@@K}" ; printf \\n ; } ; args1 echo foo ;
>> args1 echo two three 'echo' 'foo'
>> 'echo' 'two' 'three'
>> ~ $
>>
>> On Wed, Jun 12, 2024, 10:52 PM alex xmb sw ratchev
>> wrote:
>>
>>> ~ $ logf=$HOME/alog1 ; run1() { printf '%(%F+%T%z)T %s' -1 "$1"
>>> >>"$logf" ; (( $# > 1 )) && printf \ %s "${@:2}" >>"$logf" ; "$@" ;
>>> >>"$logf" printf \\n ; } ; run1 echo foo ; cat "$logf"
>>> foo
>>> 2024-06-12+22:51:31+0200 echo foo
>>> ~ $
>>>
>>> On Wed, Jun 12, 2024, 10:26 PM Greg Wooledge wrote:
>>>
On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote:
> "set -x" makes the ensuing commands be printed, but prefixed
> with "+ ", which makes the result look ugly, not to mention that
> the following "set +x" is echoed too (there are hacks to suppress
> the "set +x" output, but they are just hacks).
If all you want is to remove the "+ ", you can simply set the PS4
variable to an empty string.
> set -o log
> cat tmp >tmp1# or any other command
> set -o nolog
>
> producing the output on the console
>
>cat tmp >tmp1
If you want to retain redirections in the -x output, that's a whole
different issue. There is currently no way to do that. Chet would
have to implement something.
Re: REQUEST - bash floating point math support
On Thu, Jun 6, 2024 at 6:34 AM Léa Gris wrote:
>
> Le 06/06/2024 à 11:55, Koichi Murase écrivait :
>
> > Though, I see your point. It is inconvenient that we cannot pass the
> > results of arithmetic evaluations to the `printf' builtin. This
> > appears to be an issue of the printf builtin. I think the `printf'
> > builtin should be extended to interpret both forms of the numbers, the
> > locale-dependent formatted number and the floating-point literals.
>
> Another way would be to expand string representation of floating-point
> numbers using the locale.
Parameter transformations could be implemented to serve this purpose.
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 then ${var@f}
would go the other way, taking var that's in the form of a
locale-dependent formatted number, and expanding it to a C
floating-point literal.
In this scenario, any floating point numbers ingested by the bash
script would be transformed to C floating-point literals before they
are referenced or manipulated in an arithmetic context, and then they
would be transformed back into the locale-dependent formatted number
before being output from the script.
Arithmetic evaluation is performed on the right-hand side of an
assignment statement assigning to a variable declared with the -i
integer attribute. A hypothetical -E floating-point variable attribute
in bash should work the same way. As such, a variable with the -E
attribute would have to be assigned a value in a format accepted by
the arithmetic context, i.e. the C floating-point literal format.
So you'd have to do
declare -E var="${arg@f}"
in order to safely handle the locale-dependent formatted number arg,
an argument to the script.
Any floating-point literals within the script would have to be
formatted as C floating-point literals, at least if they're going to
be assigned the -E attribute or used in an arithmetic context.
And then you would have to do
printf '%f' "${var@F}"
to safely output the value using printf.
Is that unreasonable?
Zack
Re: Echoing commands
2024年6月13日(木) 5:20 Angelo Borsotti :
> This is not the same as debugging, for which set -x is devoted.
> "set -x" makes the ensuing commands be printed, but prefixed
> with "+ ", which makes the result look ugly,
PS4= (as Greg has replied)
> not to mention that
> the following "set +x" is echoed too (there are hacks to suppress
> the "set +x" output, but they are just hacks).
What are the hacks? What are the problems with them? You can have aliases:
alias @echo-on='set -x'
alias @echo-off='{ set +x; } 2>/dev/null'
> I would stress the importance of this: the purpose of scripts is
> to execute commands, informing the caller of what they execute,
> purged of all the builtins and other calculations the script does
> in order to come to the commands.
I don't think the purpose of scripts is to execute only the external
commands in general. The tasks implemented by builtins and other
calculations are allowed to be the purpose of scripts.
> Many solutions are posted in the internet, all of them are hacks with
> lots of edge cases that make them fail in presence of commands
> containing special characters, redirections, substitutions, etc.
Have you tried `set -v'? `set -v' is not a hack, (though there doesn't
seem to be a way to suppress echoing set +v).
The detailed design of how the logged commands should be filtered and
formatted depends on the purpose of each user. We already have `set
-x' and `set -v'. We can adjust the format by PS4 for `set -x'. It's
unrealistic to add a new option for every new preference of detailed
filtering and formatting. If it is really needed, you can implement
your filtering through the DEBUG trap, but it would finally be best to
explicitly write `echo COMMAND' before every COMMAND that you think is
important (unless you are lazy). It's stable and flexible.
--
Koichi
Re: REQUEST - bash floating point math support
I think that we should go ahead and do it.
On Wed, Jun 12, 2024, 5:06 PM Zachary Santer wrote:
> On Thu, Jun 6, 2024 at 6:34 AM Léa Gris wrote:
> >
> > Le 06/06/2024 à 11:55, Koichi Murase écrivait :
> >
> > > Though, I see your point. It is inconvenient that we cannot pass the
> > > results of arithmetic evaluations to the `printf' builtin. This
> > > appears to be an issue of the printf builtin. I think the `printf'
> > > builtin should be extended to interpret both forms of the numbers, the
> > > locale-dependent formatted number and the floating-point literals.
> >
> > Another way would be to expand string representation of floating-point
> > numbers using the locale.
>
> Parameter transformations could be implemented to serve this purpose.
> 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 then ${var@f}
> would go the other way, taking var that's in the form of a
> locale-dependent formatted number, and expanding it to a C
> floating-point literal.
>
> In this scenario, any floating point numbers ingested by the bash
> script would be transformed to C floating-point literals before they
> are referenced or manipulated in an arithmetic context, and then they
> would be transformed back into the locale-dependent formatted number
> before being output from the script.
>
> Arithmetic evaluation is performed on the right-hand side of an
> assignment statement assigning to a variable declared with the -i
> integer attribute. A hypothetical -E floating-point variable attribute
> in bash should work the same way. As such, a variable with the -E
> attribute would have to be assigned a value in a format accepted by
> the arithmetic context, i.e. the C floating-point literal format.
>
> So you'd have to do
> declare -E var="${arg@f}"
> in order to safely handle the locale-dependent formatted number arg,
> an argument to the script.
>
> Any floating-point literals within the script would have to be
> formatted as C floating-point literals, at least if they're going to
> be assigned the -E attribute or used in an arithmetic context.
>
> And then you would have to do
> printf '%f' "${var@F}"
> to safely output the value using printf.
>
> Is that unreasonable?
>
> Zack
>
>
Re: Echoing commands
Dear all,
thank you very much for your quick replies. The solution:
alias @echo-on='set -x'
alias @echo-off='{ set +x; } 2>/dev/null'
PS4=
Solves the problem, and relieves from writing "echo COMMAND" before each
command that should be shown.
-Angelo Borsotti
On Wed, 12 Jun 2024 at 23:21, Koichi Murase wrote:
> 2024年6月13日(木) 5:20 Angelo Borsotti :
> > This is not the same as debugging, for which set -x is devoted.
> > "set -x" makes the ensuing commands be printed, but prefixed
> > with "+ ", which makes the result look ugly,
>
> PS4= (as Greg has replied)
>
> > not to mention that
> > the following "set +x" is echoed too (there are hacks to suppress
> > the "set +x" output, but they are just hacks).
>
> What are the hacks? What are the problems with them? You can have aliases:
>
> alias @echo-on='set -x'
> alias @echo-off='{ set +x; } 2>/dev/null'
>
> > I would stress the importance of this: the purpose of scripts is
> > to execute commands, informing the caller of what they execute,
> > purged of all the builtins and other calculations the script does
> > in order to come to the commands.
>
> I don't think the purpose of scripts is to execute only the external
> commands in general. The tasks implemented by builtins and other
> calculations are allowed to be the purpose of scripts.
>
> > Many solutions are posted in the internet, all of them are hacks with
> > lots of edge cases that make them fail in presence of commands
> > containing special characters, redirections, substitutions, etc.
>
> Have you tried `set -v'? `set -v' is not a hack, (though there doesn't
> seem to be a way to suppress echoing set +v).
>
> The detailed design of how the logged commands should be filtered and
> formatted depends on the purpose of each user. We already have `set
> -x' and `set -v'. We can adjust the format by PS4 for `set -x'. It's
> unrealistic to add a new option for every new preference of detailed
> filtering and formatting. If it is really needed, you can implement
> your filtering through the DEBUG trap, but it would finally be best to
> explicitly write `echo COMMAND' before every COMMAND that you think is
> important (unless you are lazy). It's stable and flexible.
>
> --
> Koichi
>
