# [PATCH] completion: use awk for filtering the config entries 7 messages from 2024-02-16 to 2024-02-19. Participants: Beat Bolli, Junio C Hamano, Philippe Blain, Johannes Schindelin. Thread: https://gitlist.dev/t/60937 ## Beat Bolli, 2024-02-16 17:10 Subject: [PATCH] completion: use awk for filtering the config entries Message-ID: <20240216171046.927552-1-dev+git@drbeat.li> URL: https://gitlist.dev/e/20240216171046.927552-1-dev%2Bgit%40drbeat.li ``` Commits 1e0ee4087e (completion: add and use __git_compute_first_level_config_vars_for_section, 2024-02-10) and 6e32f718ff (completion: add and use __git_compute_second_level_config_vars_for_section, 2024-02-10) introduced new helpers for config completion. Both helpers use a pipeline of grep and awk to filter the list of config entries. awk is perfectly capable of filtering, so let's eliminate the grep process and move the filtering into the awk script. The "-E" grep option (extended syntax) was not necessary, as $section is a single word. While at it, wrap the over-long lines to make them more readable. Signed-off-by: Beat Bolli --- Junio, this goes on top of 'pb/complete-config' which is on next currently. contrib/completion/git-completion.bash | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 444b3efa63..fcf1afd75d 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2673,7 +2673,8 @@ __git_compute_first_level_config_vars_for_section () __git_compute_config_vars local this_section="__git_first_level_config_vars_for_section_${section}" test -n "${!this_section}" || - printf -v "__git_first_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars" | grep -E "^${section}\.[a-z]" | awk -F. '{print $2}')" + printf -v "__git_first_level_config_vars_for_section_${section}" %s \ + "$(echo "$__git_config_vars" | awk -F. "/^${section}\.[a-z]/ { print \$2 }")" } __git_compute_second_level_config_vars_for_section () @@ -2682,7 +2683,8 @@ __git_compute_second_level_config_vars_for_section () __git_compute_config_vars_all local this_section="__git_second_level_config_vars_for_section_${section}" test -n "${!this_section}" || - printf -v "__git_second_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars_all" | grep -E "^${section}\.<" | awk -F. '{print $3}')" + printf -v "__git_second_level_config_vars_for_section_${section}" %s \ + "$(echo "$__git_config_vars_all" | awk -F. "/^${section}\. URL: https://gitlist.dev/e/xmqqr0hcjorg.fsf%40gitster.g In-Reply-To: <20240216171046.927552-1-dev+git@drbeat.li> ``` Beat Bolli writes: > Commits 1e0ee4087e (completion: add and use > __git_compute_first_level_config_vars_for_section, 2024-02-10) and > 6e32f718ff (completion: add and use > __git_compute_second_level_config_vars_for_section, 2024-02-10) > introduced new helpers for config completion. > > Both helpers use a pipeline of grep and awk to filter the list of config > entries. awk is perfectly capable of filtering, so let's eliminate the > grep process and move the filtering into the awk script. Makes sense. I wonder if we can have some simple script sanity checker that catches things like this, e.g., catting a single file into pipe, grep appearing upstream of awk or sed, etc. > The "-E" grep option (extended syntax) was not necessary, as $section is > a single word. > > While at it, wrap the over-long lines to make them more readable. > > Signed-off-by: Beat Bolli > --- > > Junio, this goes on top of 'pb/complete-config' which is on next > currently. Alternatively we could redo the topic, squashing this fix in, after the release when we rewind 'next'. Thanks. > > contrib/completion/git-completion.bash | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 444b3efa63..fcf1afd75d 100644 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -2673,7 +2673,8 @@ __git_compute_first_level_config_vars_for_section () > __git_compute_config_vars > local this_section="__git_first_level_config_vars_for_section_${section}" > test -n "${!this_section}" || > - printf -v "__git_first_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars" | grep -E "^${section}\.[a-z]" | awk -F. '{print $2}')" > + printf -v "__git_first_level_config_vars_for_section_${section}" %s \ > + "$(echo "$__git_config_vars" | awk -F. "/^${section}\.[a-z]/ { print \$2 }")" > } > > __git_compute_second_level_config_vars_for_section () > @@ -2682,7 +2683,8 @@ __git_compute_second_level_config_vars_for_section () > __git_compute_config_vars_all > local this_section="__git_second_level_config_vars_for_section_${section}" > test -n "${!this_section}" || > - printf -v "__git_second_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars_all" | grep -E "^${section}\.<" | awk -F. '{print $3}')" > + printf -v "__git_second_level_config_vars_for_section_${section}" %s \ > + "$(echo "$__git_config_vars_all" | awk -F. "/^${section}\. } > > __git_config_sections= ``` ## Beat Bolli, 2024-02-16 18:29 Subject: Re: [PATCH] completion: use awk for filtering the config entries Message-ID: <4a1d3618-cebe-4c20-89ce-c5dab51af21a@drbeat.li> URL: https://gitlist.dev/e/4a1d3618-cebe-4c20-89ce-c5dab51af21a%40drbeat.li In-Reply-To: ``` On 16.02.24 18:35, Junio C Hamano wrote: > Beat Bolli writes: > >> Commits 1e0ee4087e (completion: add and use >> __git_compute_first_level_config_vars_for_section, 2024-02-10) and >> 6e32f718ff (completion: add and use >> __git_compute_second_level_config_vars_for_section, 2024-02-10) >> introduced new helpers for config completion. >> >> Both helpers use a pipeline of grep and awk to filter the list of config >> entries. awk is perfectly capable of filtering, so let's eliminate the >> grep process and move the filtering into the awk script. > > Makes sense. I wonder if we can have some simple script sanity > checker that catches things like this, e.g., catting a single file > into pipe, grep appearing upstream of awk or sed, etc. Yes, there are quite a few cases of these in t/. I'm not sure if it's worth the churn, though. At least it would make the tests faster on Windows... >> The "-E" grep option (extended syntax) was not necessary, as $section is >> a single word. >> >> While at it, wrap the over-long lines to make them more readable. >> >> Signed-off-by: Beat Bolli >> --- >> >> Junio, this goes on top of 'pb/complete-config' which is on next >> currently. > > Alternatively we could redo the topic, squashing this fix in, after > the release when we rewind 'next'. As you like. This commit would have to be split to apply to the two original commits. >> contrib/completion/git-completion.bash | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash >> index 444b3efa63..fcf1afd75d 100644 >> --- a/contrib/completion/git-completion.bash >> +++ b/contrib/completion/git-completion.bash >> @@ -2673,7 +2673,8 @@ __git_compute_first_level_config_vars_for_section () >> __git_compute_config_vars >> local this_section="__git_first_level_config_vars_for_section_${section}" >> test -n "${!this_section}" || >> - printf -v "__git_first_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars" | grep -E "^${section}\.[a-z]" | awk -F. '{print $2}')" >> + printf -v "__git_first_level_config_vars_for_section_${section}" %s \ >> + "$(echo "$__git_config_vars" | awk -F. "/^${section}\.[a-z]/ { print \$2 }")" >> } >> >> __git_compute_second_level_config_vars_for_section () >> @@ -2682,7 +2683,8 @@ __git_compute_second_level_config_vars_for_section () >> __git_compute_config_vars_all >> local this_section="__git_second_level_config_vars_for_section_${section}" >> test -n "${!this_section}" || >> - printf -v "__git_second_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars_all" | grep -E "^${section}\.<" | awk -F. '{print $3}')" >> + printf -v "__git_second_level_config_vars_for_section_${section}" %s \ >> + "$(echo "$__git_config_vars_all" | awk -F. "/^${section}\.> } >> >> __git_config_sections= ``` ## Philippe Blain, 2024-02-16 18:47 Subject: Re: [PATCH] completion: use awk for filtering the config entries Message-ID: URL: https://gitlist.dev/e/fcd3f999-a8d1-9f9d-e8fd-071b38124edc%40gmail.com In-Reply-To: ``` Hi Beat and Junio, Le 2024-02-16 à 12:35, Junio C Hamano a écrit : > Beat Bolli writes: > >> Commits 1e0ee4087e (completion: add and use >> __git_compute_first_level_config_vars_for_section, 2024-02-10) and >> 6e32f718ff (completion: add and use >> __git_compute_second_level_config_vars_for_section, 2024-02-10) >> introduced new helpers for config completion. >> >> Both helpers use a pipeline of grep and awk to filter the list of config >> entries. awk is perfectly capable of filtering, so let's eliminate the >> grep process and move the filtering into the awk script. > > Makes sense. Yes, thanks for improving that! > I wonder if we can have some simple script sanity > checker that catches things like this, e.g., catting a single file > into pipe, grep appearing upstream of awk or sed, etc. > >> The "-E" grep option (extended syntax) was not necessary, as $section is >> a single word. >> >> While at it, wrap the over-long lines to make them more readable. >> >> Signed-off-by: Beat Bolli >> --- >> >> Junio, this goes on top of 'pb/complete-config' which is on next >> currently. > > Alternatively we could redo the topic, squashing this fix in, after > the release when we rewind 'next'. > > Thanks. Actually you already merged this topic to master in 89400c3615, so it would go on top, no ? Thanks, Philippe. ``` ## Junio C Hamano, 2024-02-16 20:12 Subject: Re: [PATCH] completion: use awk for filtering the config entries Message-ID: URL: https://gitlist.dev/e/xmqqwmr4gocd.fsf%40gitster.g In-Reply-To: ``` Philippe Blain writes: >>> Junio, this goes on top of 'pb/complete-config' which is on next >>> currently. >> >> Alternatively we could redo the topic, squashing this fix in, after >> the release when we rewind 'next'. >> >> Thanks. > > Actually you already merged this topic to master in 89400c3615, so it would > go on top, no ? Ah, then that's fine. I didn't check what I read above myself before responding X-<. ``` ## Johannes Schindelin, 2024-02-18 21:58 Subject: Re: [PATCH] completion: use awk for filtering the config entries Message-ID: URL: https://gitlist.dev/e/aa3e36a1-52d3-0c15-b70b-83c6664757f5%40gmx.de In-Reply-To: <4a1d3618-cebe-4c20-89ce-c5dab51af21a@drbeat.li> ``` Hi Beat, On Fri, 16 Feb 2024, Beat Bolli wrote: > On 16.02.24 18:35, Junio C Hamano wrote: > > Beat Bolli writes: > > > > > Commits 1e0ee4087e (completion: add and use > > > __git_compute_first_level_config_vars_for_section, 2024-02-10) and > > > 6e32f718ff (completion: add and use > > > __git_compute_second_level_config_vars_for_section, 2024-02-10) > > > introduced new helpers for config completion. > > > > > > Both helpers use a pipeline of grep and awk to filter the list of config > > > entries. awk is perfectly capable of filtering, so let's eliminate the > > > grep process and move the filtering into the awk script. > > > > Makes sense. I wonder if we can have some simple script sanity > > checker that catches things like this, e.g., catting a single file > > into pipe, grep appearing upstream of awk or sed, etc. > > Yes, there are quite a few cases of these in t/. I'm not sure if it's worth > the churn, though. At least it would make the tests faster on Windows... Thank you for caring about the speed on Windows! Ciao, Johannes ``` ## Junio C Hamano, 2024-02-19 17:19 Subject: Re: [PATCH] completion: use awk for filtering the config entries Message-ID: URL: https://gitlist.dev/e/xmqq4je4e5i9.fsf%40gitster.g In-Reply-To: ``` Johannes Schindelin writes: >> > Makes sense. I wonder if we can have some simple script sanity >> > checker that catches things like this, e.g., catting a single file >> > into pipe, grep appearing upstream of awk or sed, etc. >> >> Yes, there are quite a few cases of these in t/. I'm not sure if it's worth >> the churn, though. At least it would make the tests faster on Windows... > > Thank you for caring about the speed on Windows! Yup, that is why I asked ;-) ```