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...

On Tue, Apr 8, 2025 at 7:04 AM Greg Wooledge wrote: > > 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 co

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

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: 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 > 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 f

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 multiline command,

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:43 PM, Oğuz wrote: 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 $ After the second invocation of `ls' I a

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

Re: Feature Request: Allow compgen to store results on a variable

On Mon, Feb 21, 2022 at 2:23 AM konsolebox wrote: > > Commonly `readarray -t`, a pipe, and a subshell is used to get the > results of compgen but this has two problems: > > - It uses a pipe and a subshell > - Values having newlines will be split > > Those can be prevented if another option is adde

Feature request - make type show that a builtin is a loadable

I think it's a good idea for the type builtin to distinguish between static and loadable builtins, and for debugging scripts that use loadable builtins, it would be useful to be able to see which file got loaded. For example in cases where BASH_LOADABLES_PATH was unintentionally unset or set to a w

Re: feature request: new builtin `defer`, scope delayed eval

On Sat, Oct 8, 2022, 12:03 Oğuz wrote: > 8 Ekim 2022 Cumartesi tarihinde Cynthia Coan yazdı: > > > > [...] I think > > use cases outside of cleanup are relatively sparse, [...] > > > There. There already are several ways to do cleanup on exit/return using > existing features, why add one more? >

Re: feature request: new builtin `defer`, scope delayed eval

Hi Koichi, > (This is just a side note about `local -' but unrelated to the main > discussion): I didn't mention it because I thought `set -e' is merely > an example to demonstrate the behavior of `defer', but if the handling > of `set -e' is one of the main motivations for requesting `defer', I

Re: feature request: new builtin `defer`, scope delayed eval

Hi Cynthia, thank you for your reply. 2022年10月8日(土) 17:26 Cynthia Coan : > > I agree the proper implementation of `defer' by the RETURN trap could > > be tricky (as described in "notes" in my previous reply), but it's > > definitely not as hard as you initially posted (one 12-line function > > vs

Re: feature request: new builtin `defer`, scope delayed eval

8 Ekim 2022 Cumartesi tarihinde Cynthia Coan yazdı: > > [...] I think > use cases outside of cleanup are relatively sparse, [...] There. There already are several ways to do cleanup on exit/return using existing features, why add one more? > [...] With your syntax you still have to be aware of

Re: feature request: new builtin `defer`, scope delayed eval

Hi Koichi, > I did notice your link to the Gist example, but I have to say that it > misuses the RETURN trap. As I have written in the previous reply, the > RETURN trap is already designed to be function-local so that it suits > your use cases. However, the Gist version somehow disables the > func

Re: feature request: new builtin `defer`, scope delayed eval

Hi Lawrence, 2022年10月8日(土) 16:04 Lawrence Velázquez : > On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote: > > [...]. One thing to note is that the RETURN trap > > should be cleaned up inside the RETURN trap itself by running `trap - > > RETURN', or otherwise the RETURN trap is erroneously cons

Re: feature request: new builtin `defer`, scope delayed eval

Let me update the example implementation of ``defer''. I think this is more readable: function defer { local trap eval "trap=($(trap -p RETURN))" trap -- " if [[ \$FUNCNAME != defer ]]; then trap - RETURN $1 ${trap[2]-} fi" RETURN } declare -ft defer I also tested

Re: feature request: new builtin `defer`, scope delayed eval

Hi Cynthia, 2022年10月8日(土) 15:56 Cynthia Coan : > I'm well aware that "defer"/"safe trap appending" can be implemented > today as it stands (see the original email in this chain, which links > to an example that I've used in a more reduced form). I did notice your link to the Gist example, but I h

Re: feature request: new builtin `defer`, scope delayed eval

On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote: > 2022年10月8日(土) 12:04 Cynthia Coan : >> [...] >> >> Otherwise, I think we can perhaps reword this into two smaller >> features: "function local trap signals", > > The existing RETURN trap is exactly the trap that can be used to clean > up resour

Re: feature request: new builtin `defer`, scope delayed eval

> I don't think this would be a feature worth the time to implement and > the complexity it would introduce. Is there any other use case for this > than cleaning up temporary files on function return? Yeah! I think that's a fair point since it seems like we're landing on traps being the way forwar

Re: feature request: new builtin `defer`, scope delayed eval

Hi Koichi, I'm well aware that "defer"/"safe trap appending" can be implemented today as it stands (see the original email in this chain, which links to an example that I've used in a more reduced form). I also have in the past written several helpers for safely appending to a trap (yours in parti

Re: feature request: new builtin `defer`, scope delayed eval

2022年10月8日(土) 12:04 Cynthia Coan : > [...] > > Otherwise, I think we can perhaps reword this into two smaller > features: "function local trap signals", The existing RETURN trap is exactly the trap that can be used to clean up resources local to functions and is already ``function-local'' unless t

Re: feature request: new builtin `defer`, scope delayed eval

On 10/8/22 6:03 AM, Cynthia Coan wrote: Otherwise, I think we can perhaps reword this into two smaller features: "function local trap signals", and I don't think this would be a feature worth the time to implement and the complexity it would introduce. Is there any other use case for this than

Re: feature request: new builtin `defer`, scope delayed eval

I definitely got the inspiration of the name from the Go programming language. There are several other languages who use similar concepts when dealing with cleanup where something like an RAII pattern to free resources. It sounds like we're leaning towards trap, over a new built-in which I think i

Re: feature request: new builtin `defer`, scope delayed eval

The Go programming language has a "defer" statement which is used considerably for exactly this purpose. So we know that it's useful in practice. The question remains what is a good way to introduce it into Bash. As others have noted, there is already a "trap" with similar functionality. I'm no

Re: feature request: new builtin `defer`, scope delayed eval

I think that's certainly a fair option, and a potential solution. The reason for introducing a new "builtin" as opposed to utilizing a trap is because safely appending to a trap can be filled with holes. Since trap always overwrites what is in the trap, you have to be aware of what is already in th

Re: feature request: new builtin `defer`, scope delayed eval

On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote: > I'd specifically like to propose a new built-in called `defer` which > acts like `eval` however is not parsed/expanded/run until it's scope > is leaving. Hopefully "scope" is the correct word, I'm imagining it > running at the same time a loca

feature request: new builtin `defer`, scope delayed eval

Hey all, I've started working on this idea, and before getting too far I'd like to get general feedback on the feature before going too far. I'd specifically like to propose a new built-in called `defer` which acts like `eval` however is not parsed/expanded/run until it's scope is leaving. Hopeful

Re: Feature request

On Wed, Jul 6, 2022 at 1:20 PM Brad Hayes wrote: > Perhaps something similar to PHP's __DIR__ and __FILE__ constants? > > ``` > > source "$__DIR/file.ext" #$__DIR == the absolute path to the current > scripts location. > > ``` I think $__DIR__ and $__FILE__ are better for less brain memory overhe

Re: Feature request

On Jul 06 2022, Brad Hayes wrote: > Perhaps something similar to PHP's __DIR__ and __FILE__ constants? You can get that from $0. -- 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: Feature request

On Wed, Jul 06, 2022 at 01:25:38PM +1000, Brad Hayes wrote: > source "$__DIR/file.ext" #$__DIR == the absolute path to the current > scripts location. https://mywiki.wooledge.org/BashFAQ/028

Re: Feature request

Hello Brad! > It would be fantastic if there was a nicer way to source files from the > same folder instead of copy-pasting complicated logic in every script. I'm not sure if I understand your questions correctly, but did you try source "${0%/*}/file.ext" ? >- my sourceables also need logi

Feature request

Hey, guys I just joined to ask this please forgive me if I am in the wrong place. First of all big fan of bash, I use it a LOT 🚀. It would be fantastic if there was a nicer way to source files from the same folder instead of copy-pasting complicated logic in every script. Perhaps something si

Re: Feature Request: Add option to make completed values always become properly escaped

On Mon, Mar 7, 2022, 23:16 Chet Ramey, wrote: > On 2/26/22 2:01 PM, konsolebox wrote: > > > I think an option like 'escape' that simply escapes COMPREPLY > > values when used for completion and doesn't compare it to existing > > filesystem objects will be better. > > OK. I'll consider something l

Re: Feature Request: Add option to make completed values always become properly escaped

On 2/26/22 2:01 PM, konsolebox wrote: I think an option like 'escape' that simply escapes COMPREPLY values when used for completion and doesn't compare it to existing filesystem objects will be better. OK. I'll consider something like this for the next version. Bash-5.2/ Readline-8.2 are featu

Re: Feature Request: Add option to make completed values always become properly escaped

On Fri, Feb 25, 2022 at 2:46 PM Chet Ramey wrote: > > On 2/25/22 3:29 AM, konsolebox wrote: > > On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote: > >> What does `properly quoted' mean here and how does it differ from the > >> quoting you get when you force complete to treat the completions as > >

Re: Feature Request: Add option to make completed values always become properly escaped

On 2/25/22 3:29 AM, konsolebox wrote: On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote: What does `properly quoted' mean here and how does it differ from the quoting you get when you force complete to treat the completions as filenames with `complete -o filenames'? I realized that a "quote al

Re: Feature Request: Add option to make completed values always become properly escaped

On Fri, Feb 25, 2022 at 8:29 AM konsolebox wrote: > What I need more is an option that allows replacing the current > word including the quote (', ", or $') that begins it with the result > as is rather than appending the result to the quote. ... because the result is already quoted with `printf

Re: Feature Request: Add option to make completed values always become properly escaped

On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote: > What does `properly quoted' mean here and how does it differ from the > quoting you get when you force complete to treat the completions as > filenames with `complete -o filenames'? I realized that a "quote all ' option is not what I want since

Re: Feature Request: Add option to make completed values always become properly escaped

On 2/20/22 1:40 PM, konsolebox wrote: It's difficult to make values like 'release[remote]' to become properly quoted or escaped because if the current word starts with a quote (which can be a ', a ", or a $'), a manually quoted COMPREPLY value like release\[remote\] will make the completed value

Feature Request: Add option to make completed values always become properly escaped

It's difficult to make values like 'release[remote]' to become properly quoted or escaped because if the current word starts with a quote (which can be a ', a ", or a $'), a manually quoted COMPREPLY value like release\[remote\] will make the completed value include the backslashes (e.g. 'release\[

Feature Request: Allow compgen to store results on a variable

Commonly `readarray -t`, a pipe, and a subshell is used to get the results of compgen but this has two problems: - It uses a pipe and a subshell - Values having newlines will be split Those can be prevented if another option is added. E.g.: compgen -O array_var ... -- konsolebox

Re: Feature request

> > On 1/11/22 6:24 AM, Tathastu Pandya via Bug reports for the GNU Bourne > Again SHell wrote: > > Just as PROMPT COMMAND thats get executed every time before any commamd. > Is there a way to execute predefined command after every command is > executedeg. Automatically record the exit status of cu

Re: Feature request

On 1/11/22 6:24 AM, Tathastu Pandya via Bug reports for the GNU Bourne Again SHell wrote: > Just as PROMPT COMMAND thats get executed every time before any commamd. Is > there a way to execute predefined command after every command is executedeg. > Automatically record the exit status of currentk

Re: Feature request

see maybe the debug trap On Tue, Jan 11, 2022, 16:12 Tathastu Pandya via Bug reports for the GNU Bourne Again SHell wrote: > Just as PROMPT COMMAND thats get executed every time before any commamd. > Is there a way to execute predefined command after every command is > executedeg. Automatically

Feature request

Just as PROMPT COMMAND thats get executed every time before any commamd. Is there a way to execute predefined command after every command is executedeg. Automatically record the exit status of currentky executed command to history file immeduately after a command ends or ctrl+c or any break or e

Re: Feature Request: Allow each completion to have their own wordbreaks

On 12/18/21 4:43 AM, konsolebox wrote: Right now I'm trying to perfect this completion script for rake (https://git.io/JDaSA), but the problem is it has to rely on modifying the COMP_WORDBREAKS variable so it doesn't contain '=' and ':'. This conflicts with git's completion script at least which

Feature Request: Allow each completion to have their own wordbreaks

Right now I'm trying to perfect this completion script for rake (https://git.io/JDaSA), but the problem is it has to rely on modifying the COMP_WORDBREAKS variable so it doesn't contain '=' and ':'. This conflicts with git's completion script at least which prefers `:` to be assigned, and I'm not

  1   2   3   4   5   6   >