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

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,

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

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 >

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

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

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

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

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

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

Re: feature request array expansion of keys values pairs and for k v loop

2021年8月19日(木) 9:31 Léa Gris : > [...] > > I'd like some syntax to expand both keys and values into a single > scalar. Something like a at sign or another symbol meaning both are > expanded: > > # Expand key values pairs as distinct arguments > printf '%s ' "${@array[@]}" > printf \\n FYI, zsh prov

Re: Feature request: index of index

Meanwhile you may use functions to setup your variables something along those lines. PW$ function first-index { echo $1; } PW$ function last-index { shift $(($#-1)) ; echo $1; } PW$ declare -a array=([5]="hello" [11]="world" [42]="here") PW$ declare -i first_index=$(first-index ${!array[@]}) PW$

Re: Feature request: Empty associative-array keys

On 4/8/21 6:02 PM, Koichi Murase wrote: No error message for `unset 'a[]''? It's still a valid function name, and `unset' attempts to unset variables first, then functions. POSIX leaves that unspecified; that is how bash behaves. Bash doesn't print an error message if you try to unset a functi

Re: feature request: ${ regex s expander, and multiple expandrs inside one

On Fri, Feb 05, 2021 at 09:29:49PM +0100, Alex fxmbsw7 Ratchev wrote: > .. > > var=mynewfoo > printf ${var~~n[^f]+} > -> > myfoo > > and also multiple expanders inside one statement would greatly speed up > processment and also fulfill old greatly coding wanting possibilities This could be

Re: feature request: ${ regex s expander, and multiple expandrs inside one

i actually hope for also replacement code that can use regex grouped data On Fri, Feb 5, 2021 at 10:13 PM Chet Ramey wrote: > On 2/5/21 3:29 PM, Alex fxmbsw7 Ratchev wrote: > > .. > > > > var=mynewfoo > > printf ${var~~n[^f]+} > > -> > > myfoo > > So you want to remove portions of a vari

Re: feature request: ${ regex s expander, and multiple expandrs inside one

On 2/5/21 3:29 PM, Alex fxmbsw7 Ratchev wrote: .. var=mynewfoo printf ${var~~n[^f]+} -> myfoo So you want to remove portions of a variable's value that match a regex? and also multiple expanders inside one statement would greatly speed up processment and also fulfill old greatly codi

Re: Feature Request: scanf-like parsing

25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: > On 1/25/21 12:58 PM, Oğuz wrote: > > I rarely use eval, but when I do, it works just fine. >> > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. > Heh. Made it my avat

Re: Feature Request: scanf-like parsing

On 1/26/21 2:46 AM, Chet Ramey wrote: > On 1/25/21 12:58 PM, Oğuz wrote: >> I rarely use eval, but when I do, it works just fine. > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. Not sure whether attachments are allowe

Re: Feature Request: scanf-like parsing

On 1/25/21 2:51 PM, Greg Wooledge wrote: On Mon, Jan 25, 2021 at 02:46:24PM -0500, Chet Ramey wrote: On 1/25/21 12:58 PM, Oğuz wrote: I rarely use eval, but when I do, it works just fine. Someone should create a meme with this text superimposed on an image of the Dos Equis most interesting m

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 02:46:24PM -0500, Chet Ramey wrote: > On 1/25/21 12:58 PM, Oğuz wrote: > > > I rarely use eval, but when I do, it works just fine. > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. https://imgfli

Re: Feature Request: scanf-like parsing

On 1/25/21 12:58 PM, Oğuz wrote: I rarely use eval, but when I do, it works just fine. Someone should create a meme with this text superimposed on an image of the Dos Equis most interesting man in the world. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ar

Re: Feature Request: scanf-like parsing

On 1/25/21 12:53 PM, Greg Wooledge wrote: On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote: This is good advice. If the double-quoting the @K transformation performs is not what you need, use the @Q transformation to get something closer. Those don't do the same thing, though. Yes,

Re: Feature Request: scanf-like parsing

Le 25/01/2021 à 18:58, Oğuz écrivait : I rarely use eval, but when I do, it works just fine. I can't really agree with the sentiment of your article, sorry. I use eval when I am sure there is no other safer way. Mean, if I can achieve the same with declare foo="dynamically generated content"

Re: Feature Request: scanf-like parsing

word, hopefully ppl migrate to such as 'use what a tool supports' On Mon, Jan 25, 2021, 19:22 Oğuz wrote: > On Mon, Jan 25, 2021 at 9:15 PM Greg Wooledge wrote: > > > Again, there are many different authors of that page. Think of it as > > a community FAQ, rather than mine. It was written by

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 9:15 PM Greg Wooledge wrote: > Again, there are many different authors of that page. Think of it as > a community FAQ, rather than mine. It was written by a committee, as > horrifying as that may sound. > Okay, I'm not saying I know better than the members of that ``com

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 08:58:23PM +0300, Oğuz wrote: > This sentence alone reflects that article's perspective on the issue. > > "eval" is a common misspelling of "evil". > > I rarely use eval, but when I do, it works just fine. I can't really agree > with the sentiment of your article, sorry. A

Re: Feature Request: scanf-like parsing

assoc copy without eval root@localhost:~# unset orig copy root@localhost:~# declare -A orig=( [a\ key]=a\ value [another\ key]=another\ value ) ; rep=$( declare -p orig ) root@localhost:~# rep=$( declare -p orig ) root@localhost:~# declare -A "copy=${rep#*=}" root@localhost:~# declare -p copy de

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 8:06 PM Greg Wooledge wrote: > It's a tricky thing to deal with. Eli referenced my wiki, which has a > page dedicated to it, with contributions from many different authors. > The resulting quasi-consensus is complex and perhaps even a little > bit self-contradictory as a

Re: Feature Request: scanf-like parsing

On 1/25/21 12:48 PM, Alex fxmbsw7 Ratchev wrote: you havent been on #bash freenode irc where it is the reverse to this quote 'no one ..', where also 'bash is no coding language' and x other invalid things are common, to all i disagree, but the masses of ignorant wrong teachen ppl overwealth me an

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote: > This is good advice. If the double-quoting the @K transformation performs > is not what you need, use the @Q transformation to get something closer. Those don't do the same thing, though. unicorn:~$ declare -A aa=([a key]="a value" [$'

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021, 17:50 Eli Schwartz wrote: > On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: > > cool, now that u're the main bash coder greycat and co wont fall like > > cannibals over you for using eval > > cheers for old code > > No one ever said eval is evil, if you're using it solely t

Re: Feature Request: scanf-like parsing

On 1/25/21 11:59 AM, Greg Wooledge wrote: The problem with eval is that for every OK usage, there are a thousand incorrect and dangerous uses. Avoid those, by being absolutely sure you know what you're doing, and why you're doing it. The shell is a sharp tool. -- ``The lyf so short, the craf

Re: Feature Request: scanf-like parsing

On 1/25/21 11:59 AM, Greg Wooledge wrote: The problem with eval is that for every OK usage, there are a thousand incorrect and dangerous uses. Avoid those, by being absolutely sure you know what you're doing, and why you're doing it. This is good advice. If the double-quoting the @K transform

Re: Feature Request: scanf-like parsing

On 1/25/21 11:59 AM, Greg Wooledge wrote: On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote: 25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: declare -A copy eval copy=( "${assoc[@]@K}" ) So many reputable people contributed to the demonization of `eval' that I don't think I can convinc

Re: Feature Request: scanf-like parsing

On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote: > 25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: > > declare -A copy > > eval copy=( "${assoc[@]@K}" ) > > So many reputable people contributed to the demonization of `eval' that I > don't think I can convince anyone that there's nothing w

Re: Feature Request: scanf-like parsing

On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: cool, now that u're the main bash coder greycat and co wont fall like cannibals over you for using eval cheers for old code No one ever said eval is evil, if you're using it solely to consume the output of a shell builtin functionality specifica

Re: Feature Request: scanf-like parsing

25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: > > There has been code to do this for a long time. It's currently tagged for > bash-5.2. If you want to play around with it, look in subst.c for > shouldexp_replacement and its caller, and uncomment them. You'll have to > wait for the next devel

Re: Feature Request: scanf-like parsing

i completly agree, .. just dunno why others dont :) On Mon, Jan 25, 2021, 17:31 Chet Ramey wrote: > On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: > > cool, now that u're the main bash coder greycat and co wont fall like > > cannibals over you for using eval > > cheers for old code > > The she

Re: Feature Request: scanf-like parsing

On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: cool, now that u're the main bash coder greycat and co wont fall like cannibals over you for using eval cheers for old code The shell is a sharp tool. If you're going to use it to try and cut your fingers off, it's not going to stop you. If you

Re: Feature Request: scanf-like parsing

cool, now that u're the main bash coder greycat and co wont fall like cannibals over you for using eval cheers for old code On Mon, Jan 25, 2021, 17:18 Chet Ramey wrote: > On 1/25/21 10:17 AM, Chet Ramey wrote: > > I agree that it might be more useful if it > > expanded to multiple words in cont

Re: Feature Request: scanf-like parsing

On 1/25/21 10:17 AM, Chet Ramey wrote: I agree that it might be more useful if it expanded to multiple words in contexts like copy=( "${assoc[@]@K}" ) I forgot to mention that since the keys and values are both quoted so they can be reused, you can copy an associative array using a key-value a

Re: Feature Request: scanf-like parsing

On 1/22/21 11:54 AM, Oğuz wrote: Since everyone's making feature requests here, it'd be a shame if I didn't participate. I think it'd be better if `${assoc[@]@K}' expanded to a word list instead of a single word. It does, when it's subject to word splitting. In contexts where no word splittin

Re: Feature Request: Python-like string split and join

On Sat, Jan 23, 2021 at 11:17 PM William Park wrote: > I'm running out of special characters, and I don't want another operator > or syntax that I can't remember 2 weeks from now. :-) That's my main > issue with Zsh. I concur, I find the expansion operators devilishly hard to remember!

Re: Feature Request: Python-like string split and join

On Sun, Jan 24, 2021 at 11:29:46AM +0800, Koichi Murase wrote: > 2021年1月24日(日) 10:22 William Park : > Is there a background for choosing a semicolon to split words? Zsh has > a similar feature with a different syntax: I'm running out of special characters, and I don't want another operator or synt

  1   2   3   4   >