Re: /dev/tcp feature request...

On Wed, Apr 9, 2025 at 8:48 AM A. James Lewis wrote: > > Yes, this is how I am doing it currently, but remember that once you > cut that subshell loose, you cannot easily get a response from it and > certainly can't pass variables back... and you are more or less forced > to wait for a sensible ti

Re: /dev/tcp feature request...

++ On Fri, Apr 11, 2025, 17:21 Chet Ramey wrote: > On 4/11/25 11:03 AM, microsuxx wrote: > > same error as eof i'd say .. > > No. The file descriptor is invalid. There is a difference between a read > error (-1/EINVAL) and EOF (0). > > -- > ``The lyf so short, the craft so long to lerne.'' - Cha

Re: /dev/tcp feature request...

On 4/10/25 7:51 PM, A. James Lewis wrote: I'm not quite sure about that, I would be trying to get back the file descriptor to use for a period and then close it... so if it fails to open, then I don't know if "redirection error" makes sense, but then again, I'm not sure what would the correct err

Re: /dev/tcp feature request...

On 4/11/25 11:03 AM, microsuxx wrote: same error as eof i'd say .. No. The file descriptor is invalid. There is a difference between a read error (-1/EINVAL) and EOF (0). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Ch

Re: /dev/tcp feature request...

same error as eof i'd say .. On Fri, Apr 11, 2025, 01:53 A. James Lewis wrote: > I'm not quite sure about that, I would be trying to get back the file > descriptor to use for a period and then close it... so if it fails to > open, then I don't know if "redirection error" makes sense, but then >

Re: /dev/tcp feature request...

I'm not quite sure about that, I would be trying to get back the file descriptor to use for a period and then close it... so if it fails to open, then I don't know if "redirection error" makes sense, but then again, I'm not sure what would the correct error be. Certainly I would just be checking f

Re: /dev/tcp feature request...

On Tuesday, April 8, 2025, A. James Lewis wrote: > > I have however found it extremely frustrating to open TCP connections > via /dev/tcp, because there appears to be no way to control the > timeout! Same. It'd be nice if bash gave up after $TMOUT seconds -- Oğuz

Re: /dev/tcp feature request...

On 4/7/25 6:24 PM, A. James Lewis wrote: I've not been around this mailing list all too long, so I don't know if this has been debated before, but I have always attempted to avoid using external programs where functionality within bash can meet a requirement. Doing this allows my scripts to be m

Re: /dev/tcp feature request...

Yes, this is how I am doing it currently, but remember that once you cut that subshell loose, you cannot easily get a response from it and certainly can't pass variables back... and you are more or less forced to wait for a sensible timeout, even tho the actual connection might take a much short

Re: /dev/tcp feature request...

[[ -d /proc/"$!" ]] On Tue, Apr 8, 2025, 16:33 Andreas Schwab wrote: > On Apr 08 2025, MacBeth wrote: > > > while ((dur /dev/null; do > > You can use kill -0 $! to check if the process still exists. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 197

Re: /dev/tcp feature request...

On Apr 08 2025, MacBeth wrote: > while ((dur /dev/null; do You can use kill -0 $! to check if the process still exists. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis wrote: > > > > I have always attempted to avoid > > using external programs where functionality within bash can meet a > > requirement. Doing this allows my scripts to be more reliable, and not > > de

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > script begin ... sample output being: $ . tcp.sh HTTP/1.0 200 OK Done with: www.google.com HTTP/1.0 200 OK Done with: www.example.com sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... wa

Re: /dev/tcp feature request...

On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis wrote: > > I have always attempted to avoid > using external programs where functionality within bash can meet a > requirement. Doing this allows my scripts to be more reliable, and not > depend on those external tools being installed... > > I have ho

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 7:16 AM Zachary Santer wrote: > > Is there a good tutorial on how to actually use /dev/tcp? > I found a number of helpful results on google... https://www.google.com/search?q=%2Fdev%2Ftcp For instance: https://medium.com/@stefanos.kalandaridis/bash-ing-your-network-

Re: /dev/tcp feature request...

prompt. Bash terminates after waiting for that number of seconds if a complete line of input does not arrive. A *fourth* meaning. Is there a good tutorial on how to actually use /dev/tcp? I imagine you've got to write and send HTTP request headers and then read and handle response headers

Re: /dev/tcp feature request...

On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > On Tuesday, April 8, 2025, A. James Lewis wrote: > > I have however found it extremely frustrating to open TCP connections > > via /dev/tcp, because there appears to be no way to control the > > timeout! > > Same. It'd be nice if bash gave up

/dev/tcp feature request...

I've not been around this mailing list all too long, so I don't know if this has been debated before, but I have always attempted to avoid using external programs where functionality within bash can meet a requirement. Doing this allows my scripts to be more reliable, and not depend on those exter

request: highlighting/combo boxes on commands

You can do ffmpeg -i intro.mpv output.mpv and when you cursor over ffmpeg it highlights and over output.mpv you can do ctrl+enter and it'll list file contents it should be as easy as if (cursor = word) highlight(word) or if (text->word = text->highlight) show(combo_box) and a customizable pr

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On Saturday, September 21, 2024, Chet Ramey wrote: > On 9/21/24 1:03 AM, Oğuz wrote: > >> On Saturday, September 21, 2024, Koichi Murase > > wrote: >> >> Emacs has `auto-mode-alist'. VS Code has `files.associations'. >> >> >> I think he meant a command line opti

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On 9/21/24 1:03 AM, Oğuz wrote: On Saturday, September 21, 2024, Koichi Murase > wrote: Emacs has `auto-mode-alist'. VS Code has `files.associations'. I think he meant a command line option. Like something you can put in FCEDIT I did. But if there aren't an

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On Saturday, September 21, 2024, Koichi Murase wrote: > > Emacs has `auto-mode-alist'. VS Code has `files.associations'. > I think he meant a command line option. Like something you can put in FCEDIT -- Oğuz

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

> Do these editors have an option that sets the language for syntax > checking? I don't know. I usually use Emacs, so I'm only familiar with Emacs. For Emacs, yes, and I've already submitted a patch to address this issue to the Emacs mailing list. But clearly, not all editors are as highly custo

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

2024年9月21日(土) 1:09 Chet Ramey : > On 9/20/24 2:41 AM, shynur . wrote: > > `fc` will create a temporary file named something > > like "bash-fc.Esf9by", which seldom benefits from > > editors that use *suffixes* to infer what syntax > > highlighting should be enabled. > > Do these editors have an opt

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On 9/20/24 2:41 AM, shynur . wrote: `fc` will create a temporary file named something like "bash-fc.Esf9by", which seldom benefits from editors that use *suffixes* to infer what syntax highlighting should be enabled. Do these editors have an option that sets the language for syntax checking?

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

In 2024 an editor having such a simplistic approach counts as a bug. But perhaps adding a variable would allow anyone to nominate their own favourite, such as as BASHFC_TMPNAM=/tmp/bash-fc.$$.XX.sh Alternatively, perhaps an extra line could be inserted at the start of the b file, like « #!fc-

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On Fri, Sep 20, 2024 at 12:00 PM shynur . wrote: > Editors needn't give "bash-fc.NN" special handling, IMO. A good editor would.

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

Oğuz: > > shynur: > > > > Oğuz: > > > > > > shynur: > > > > > > > > "bash-fc.Esf9by", which seldom benefits from editors > > > > that use *suffixes* to infer what syntax highlighting > > > > should be enabled. > > > > > > For example? > > > > When Emacs opens a file named "bash-fc.NN.bash", it'

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On Fri, Sep 20, 2024 at 11:20 AM shynur . wrote: > - When Emacs opens a file named "bash-fc.NN.bash", > it'll enable sh-mode automatically Vim does that without the .bash extension. What stops Emacs from doing the same?

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

- When Emacs opens a file named "bash-fc.NN.bash", it'll enable sh-mode automatically, and even start a LSP server for Bash if configured properly. - VS Code behaves similarly. If you've never used a code editor with automatic syntax highlighting, give them a try.

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

On Friday, September 20, 2024, shynur . wrote: > > editors that use *suffixes* to infer what syntax > highlighting should be enabled. > For example? -- Oğuz

[feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

`fc` will create a temporary file named something like "bash-fc.Esf9by", which seldom benefits from editors that use *suffixes* to infer what syntax highlighting should be enabled. (This improvement may not only apply to `fc`.) -- shynur

Re: Feature request: process title with exec -a "" for oneself

On 9/5/24 8:37 PM, Lockywolf wrote: Chet Ramey writes: So I assume that you want to change the kernel's idea of the process arguments as seen and displayed by `ps'. If so, I'm not really interested in adding that as a feature. It doesn't seem to add anything for shell users. Well, I am a sh

Re: Feature request: process title with exec -a "" for oneself

On Fri, Sep 06, 2024 at 08:37:54AM +0800, Lockywolf wrote: > >I think this is appropriate for a loadable builtin. This one is Linux- > >specific. > > I am not experienced enough to have an opinion on whether a loadable > built-in is better than a feature of "exec". A loadable builtin is a builtin

Re: Feature request: process title with exec -a "" for oneself

Chet Ramey writes: > So I assume that you want to change the kernel's idea of the process > arguments as seen and displayed by `ps'. If so, I'm not really interested > in adding that as a feature. It doesn't seem to add anything for shell > users. Well, I am a shell user :). I would really lov

Re: Feature request: process title with exec -a "" for oneself

On 9/4/24 5:54 PM, Emanuele Torre wrote: Not super relevant, but I have a bash loadable builtin that can set the script's proctitle that I wrote for fun ~1 year ago. I think this is appropriate for a loadable builtin. This one is Linux- specific. -- ``The lyf so short, the craft so long to le

Re: Feature request: process title with exec -a "" for oneself

I think your idea of using exec -a '' with no positional arguments to set it is pretty cool, since exec -a changes the argv[0] of the invoked process and exec with redirections an no arguments applies redirections to the current shell permanently! Not super relevant, but I have a bash loadable

Re: Feature request: process title with exec -a "" for oneself

On 8/31/24 10:43 PM, Lockywolf wrote: Dear Bash developers, May I ask for a small feature to be added to bash? At the moment exec changes IO redirections for the newly started processes, but if there is no command for exec'ing, it changes those redirections for the bash process itself. The exe

Re: Feature request: process title with exec -a "" for oneself

On Sun, 1 Sept 2024 at 12:43, Lockywolf < for_bug-bash_gnu.org_2024-09...@lockywolf.net> wrote: > Dear Bash developers, > > May I ask for a small feature to be added to bash? > > At the moment exec changes IO redirections for the newly started > processes, but if there is no command for exec'ing,

Feature request: process title with exec -a "" for oneself

Dear Bash developers, May I ask for a small feature to be added to bash? At the moment exec changes IO redirections for the newly started processes, but if there is no command for exec'ing, it changes those redirections for the bash process itself. The exec -a, however, allows setting the curren

Re: Env var feature request

Greg Wooledge writes: > On Tue, Jul 09, 2024 at 20:14:27 +, Erik Keever wrote: >> A --debug-envvars flag which will, when passed to bash, catch every >> time an environment variable is set and print the file/line that is >> setting it. To restrict it, "--debug-envvars FOO,BAR" to catch only >

Re: Env var feature request

On Tue, Jul 09, 2024 at 20:14:27 +, Erik Keever wrote: > A --debug-envvars flag which will, when passed to bash, catch every time an > environment variable is set and print the file/line that is setting it. To > restrict it, "--debug-envvars FOO,BAR" to catch only instances of FOO or BAR > b

Env var feature request

Hello, A recent conversation with a member of our research team leads me to propose the following feature request: A --debug-envvars flag which will, when passed to bash, catch every time an environment variable is set and print the file/line that is setting it. To restrict it, "--

Re: REQUEST - bash floating point math support

On Fri, Jun 21, 2024, 10:21 PM Chet Ramey wrote: > On 6/21/24 3:59 PM, alex xmb sw ratchev wrote: > > > > If floating point math support is added to bash, I would expect > it to > > > be able to handle floating point literals in these forms as well. > > > > I'm not planning to do th

Re: REQUEST - bash floating point math support

Anybody else with the knowledge to tackle this? I am not capable of even writing C code correctly. On Fri, Jun 21, 2024 at 4:22 PM Chet Ramey wrote: > > On 6/21/24 3:59 PM, alex xmb sw ratchev wrote: > > > > If floating point math support is added to bash, I would expect it to > > > be

Re: REQUEST - bash floating point math support

On 6/21/24 3:59 PM, alex xmb sw ratchev wrote: > If floating point math support is added to bash, I would expect it to > be able to handle floating point literals in these forms as well. I'm not planning to do this any time soon. sorry my forgetness ... why ? Because if floati

Re: REQUEST - bash floating point math support

d's restriction to a locale- specific radix character. In other places where the standard relaxes such restrictions, it does so explicitly ("if the implementation wishes to allow additional formats, blah, blah"). Now, you might be able to file an interpretation request and get the grou

Re: REQUEST - bash floating point math support

On Fri, Jun 21, 2024, 9:58 PM Chet Ramey wrote: > On 6/17/24 8:04 AM, Zachary Santer wrote: > > On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote: > >> > >> Le 17/06/2024 à 09:17, Koichi Murase écrivait : > >>> declare -i numvar=${localeFormatted/[!0-9]/.} > >> > >> This would break with negati

Re: REQUEST - bash floating point math support

On 6/17/24 8:04 AM, Zachary Santer wrote: On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote: Le 17/06/2024 à 09:17, Koichi Murase écrivait : declare -i numvar=${localeFormatted/[!0-9]/.} This would break with negative numbers. I know no other radix separator than comma or dot. If there ar

Re: REQUEST - bash floating point math support

On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote: > > Le 17/06/2024 à 09:17, Koichi Murase écrivait : > >declare -i numvar=${localeFormatted/[!0-9]/.} > > This would break with negative numbers. > > I know no other radix separator than comma or dot. If there are other > radix to replace, it can

Re: REQUEST - bash floating point math support

Le 17/06/2024 à 09:17, Koichi Murase écrivait : declare -i numvar=${localeFormatted/[!0-9]/.} This would break with negative numbers. I know no other radix separator than comma or dot. If there are other radix to replace, it can be listed in a character class. Lets say there are locales

Re: REQUEST - bash floating point math support

2024年6月17日(月) 15:56 Léa Gris : > Le 16/06/2024 à 23:44, Zachary Santer écrivait : > Anyway, this could be handled with existing bash string replacement feature: > > localeFormatted=3,1415 > declare -i numvar=${localeFormatted/,/.} Is the radix character in an arbitrary locale ensured to be either

Re: REQUEST - bash floating point math support

Le 16/06/2024 à 23:44, Zachary Santer écrivait : How do you propose to take an LC_NUMERIC-formatted floating-point literal and assign it to a variable with the numeric flag or make use of it in another type of arithmetic context? This proposal does not include conversion of locale formatted lit

Re: REQUEST - bash floating point math support

On Sat, Jun 15, 2024 at 10:56 AM Léa Gris wrote: > > On 15/06/2024 à 15:29, Koichi Murase wrote : > > at which point does the conversion happens > > The conversion to LC_NUMERIC format only happens during variable > expansion outside of a numerical context. > The numerical context can be explicit

Re: REQUEST - bash floating point math support

On Sat, Jun 15, 2024, 4:56 PM Léa Gris wrote: > On 15/06/2024 à 15:29, Koichi Murase wrote : > > at which point does the conversion happens > > The conversion to LC_NUMERIC format only happens during variable > expansion outside of a numerical context. > The numerical context can be explicit if t

Re: REQUEST - bash floating point math support

On 15/06/2024 à 15:29, Koichi Murase wrote : at which point does the conversion happens The conversion to LC_NUMERIC format only happens during variable expansion outside of a numerical context. The numerical context can be explicit if the assigned variable has a numeric flag; it is implicit

Re: REQUEST - bash floating point math support

2024年6月15日(土) 17:24 Léa Gris : > Indeed printf only knows the string value. But Bash know the variable > has a numeric flag when doing the value expansion, so it expands it > using the current LC_NUMERIC locale in this specific case. Ah, OK. I misunderstood your suggestion somehow differently (suc

Re: REQUEST - bash floating point math support

Le 15/06/2024 à 02:49, Koichi Murase écrivait : 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

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: 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: 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: REQUEST - bash floating point math support

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 then ${var@f} > would go the other way, takin

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

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 thin

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 al

Re: REQUEST - bash floating point math support

On Wed, Jun 5, 2024 at 4:08 PM Robert Elz wrote: > > That's a perfect case for scaled integers - no-one ever deals with > fractions of cents in this kind of thing (a bank won't ever tell you > that your balance is $5678.17426 for example, even if the interest > calculations computed accurately mig

Re: REQUEST - bash floating point math support

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 for

Re: REQUEST - bash floating point math support

2024年6月6日(木) 18:09 Léa Gris : > Le 06/06/2024 à 10:29, Koichi Murase écrivait : > > 2024年6月6日(木) 15:59 Léa Gris : > >> 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 expa

Re: REQUEST - bash floating point math support

Le 06/06/2024 à 10:29, Koichi Murase écrivait : 2024年6月6日(木) 15:59 Léa Gris : 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 m

Re: REQUEST - bash floating point math support

2024年6月6日(木) 15:59 Léa Gris : > 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. [...] > > > >

Re: REQUEST - bash floating point math support

Le 05/06/2024 à 17:09, Greg Wooledge écrivait : On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote: Also note that to actually put floating support in the shell, more is needed than just arithmetic, you also need floating comparisons in test (or in bash, in [[ ) and a whole bunch more od

Re: REQUEST - bash floating point math support

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 B

Re: REQUEST - bash floating point math support

Date:Wed, 5 Jun 2024 13:31:20 -0400 From:Saint Michael Message-ID: | the most obvious use of floating variables would be to compare | balances and to branch based on if a balance is lower than a certain | value In addition to what Greg suggested, for the very

Re: REQUEST - bash floating point math support

I think that we should do this in the shell. I mean. It will get done at some point, in the next decades or centuries. Why not do it now? Let's compile some C library or allow inline C On Wed, Jun 5, 2024, 2:12 PM Greg Wooledge wrote: > On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wro

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wrote: > the most obvious use of floating variables would be to compare > balances and to branch based on if a balance is lower than a certain > value > I use: > t=$(python3 -c "import math;print($balance > 0)") > and the > if [ "$t" == "False

Re: REQUEST - bash floating point math support

the most obvious use of floating variables would be to compare balances and to branch based on if a balance is lower than a certain value I use: t=$(python3 -c "import math;print($balance > 0)") and the if [ "$t" == "False" ];then echo "Result <= 0 [$t] Client $clname $clid Balance $balance" fi The

Re: REQUEST - bash floating point math support

Date:Wed, 5 Jun 2024 11:09:45 -0400 From:Greg Wooledge Message-ID: | > to convert floats back into integers again, controlling how | > rounding happens). | | Ironically, that last one is the one we already *do* have. Yes, I know about printf (and while POSIX

Re: REQUEST - bash floating point math support

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 arithmeti

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote: > Also note that to actually put floating support in the shell, more is > needed than just arithmetic, you also need floating comparisons in test > (or in bash, in [[ ) and a whole bunch more odds and ends that aren't > obvious until you n

Re: REQUEST - bash floating point math support

Date:Wed, 5 Jun 2024 08:40:51 -0400 From:Zachary Santer Message-ID: | The magnification factor is handled as a | fractional number - 1.5, 1.75, etc. So, to change the magnification | factor by increments of 0.25 or 0.5, I had to print an expression into | b

REQUEST - bash floating point math support

On Tue, Jun 4, 2024 at 4:01 PM Saint Michael wrote: > > > > > It's time to add floating point variables and math to bash. > > It just makes so much easier to solve business problems without external > calls to bc or Python. > Please let's overcome the "shell complex". Let's treat bash a real langu

REQUEST

> > It's time to add floating point variables and math to bash. It just makes so much easier to solve business problems without external calls to bc or Python. Please let's overcome the "shell complex". Let's treat bash a real language.

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Tue, Feb 6, 2024 at 3:07 PM Chet Ramey wrote: > This is more like sourcing a file with `set -v' temporarily enabled (in > fact, it's very close to that). > Can't imagine POSIX would be amenable to all the 'set -v' output lines being prepended with PS2s, but that actually suffers from the same

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On 2/6/24 1:39 PM, Oğuz wrote: On Tuesday, February 6, 2024, Chet Ramey <mailto:chet.ra...@case.edu>> wrote: What's the specific request here? That bash interpret multiline commands retrieved from command history as a whole and not run the rest of the lines as separate com

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On 2/3/24 10:18 PM, Zachary Santer wrote: While I'm making feature requests. I hit C-x C-e and enter the following into my editor: var='duck' declare -p var (   var='squirrel'   declare -p var ) declare -p var I save that and exit my editor, and this is what I get in the terminal: zsant@Za

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Tuesday, February 6, 2024, Chet Ramey wrote: > > What's the specific request here? > That bash interpret multiline commands retrieved from command history as a whole and not run the rest of the lines as separate commands when the first line is changed. Try it yourself; run a mul

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

$ After the second invocation of `ls' I add a single quote and hit enter accidentally, and lose all my files. I wish it didn't happen What's the specific request here? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vit

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Sunday, February 4, 2024, Zachary Santer wrote: > > While I'm making feature requests. > I want to make one too. Multiline commands retrieved from history can be short-circuited like this: $ ls x y $ echo ' > rm * > ' >z $ $ ls x y z $ echo '' rm * ' >z > ^C $ ls

Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Fri, Feb 2, 2024 at 4:21 PM Chet Ramey wrote: > OK, I'll take that as a feature request for a future version. > While I'm making feature requests. I hit C-x C-e and enter the following into my editor: var='duck' declare -p var ( var='squirrel' dec

Re: A feature request regarding redirection to variables

On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote: > > A very common thing I need to do when writing bash is to collect both > the stdout and stderr of a command. This can be done relatively > reasonably with files but it would be very attractive to be able to > redirect these directly to a variable

A feature request regarding redirection to variables

A very common thing I need to do when writing bash is to collect both the stdout and stderr of a command. This can be done relatively reasonably with files but it would be very attractive to be able to redirect these directly to a variable some how. cmd >@stdout 2>@stderr exit_code=$? where "stdo

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

On 11/12/23 4:49 AM, Corto Beau via Bug reports for the GNU Bourne Again SHell wrote: There's another reason the shell option is not a good idea though ; it tells Bash to set the PDEATHSIG flag on all direct children, but we might want to set the flag only for some specific children. Hence the

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

The PDEATHSIG flag is indeed cleared for the child of a fork, but preserved across calls to execve. If there was a way to avoid this and propagate the flag across all descendants, I think it would mess up processes that expect their children to outlive them. The rationale for this feature pr

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

On Saturday, November 11, 2023, Corto Beau wrote: > Do you mean something like a "fork_noreparent" builtin that would call > make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the > child would have to call ? > I don't have a preference for either. I oppose it being a shell o

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

Except a wrapper program would be subject to the race condition I mentioned in my own message. Sorry for the noise. On 11/11/2023 21:54, Corto Beau wrote:  I think that a loadable builtin might be overkill for the second case, because one could write a wrapper program to set PDEATHSIG and ca

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

 I think that a loadable builtin might be overkill for the second case, because one could write a wrapper program to set PDEATHSIG and call execve on the command-line arguments. This way you'd just have to run "noreparent foo" instead of writing a shell function that calls the noreparent built

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

Do you mean something like a "fork_noreparent" builtin that would call make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the child would have to call ? I do agree that it wouldn't make sense to implement the later as a shell option, but this particular use of prctl is subj

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

On Saturday, November 11, 2023, Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov > 2023 16:05:38 +

Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death

I support this feature. On Sat, Nov 11, 2023, 11:29 AM Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 >

FEATURE REQUEST : shell option to automatically terminate child processes on parent death

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov 2023 16:05:38 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Versio

  1   2   3   4   5   6   7   >