Escaping brackets within a custom function

[lmburns]

I have this function:

cmd trash ${{
  rip -- $fx
  dunstify -a lf " Deleted File(s)" "${(F)${fx:t2}}" &&
    print -Pr "%F{3}%B*%b %F{14}%U$fx%u%f [%F{1}%Bdeleted%f%b]"
}}

The section where ${(F)${fx:t2}} is used causes all other functions and keybindings to not work. I was wondering if there was a way to escape the inner brackets to be able to use zsh code like this. I did some looking around and read over the manual and couldn't find anything on it. Though, I thought I remember reading that this was possible at one point, but I could be wrong there.

Any help would be appreciated

[kmarius]

I don't know what "${(F)${fx:t2}}" does but with bash you can trick the parser by writing something like "${(F)${fx:t2}""}".

[Serkan80]

I have a similar problem with the asterix (*) character, how can I escape that in my function ?

cmd search_in_devfiles ${{
  clear
  noglob grep -iR --exclude-dir={target,docker,perftest,mocks,docs,node_modules,packages,archive}  --include=*.{java,go,js,py,php,c,sh} "$1" $PWD 2 >/dev/null
  echo "Finished"
  read ENTER
}

I'm using ZSH and the error is happening from where "--include" starts, as soon as I remove that part then the script works.

What I've tried till far is the following:

• --include=\*.{java,go,js,php,c,sh}
• --include="*".{java,go,js,php,c,sh}
• --include=\"*".{java,go,js,php,c,sh}

And with the following config:

set shell zsh
set shellopts '-euyF'
set ifs "\n"

and these also didn't work.

[lmburns]

@Serkan80

I got your command to work. Instead of using ${{..}} I used !{{..}} and I just escaped the asterisk with a backslash. There was no need to use the noglob prefix, or to use the -F in the zsh options either. Also, when using the exclamation mark instead of the dollar sign, there is no need to use the read ENTER

For reference, this was the test example I used:

set shell zsh
# set shellopts '-eu:--shwordsplit'
set shellopts '-euy'
set ifs "\n"
set filesep "\n" 

cmd see !{{
  clear
  grep -iR --exclude-dir={aa,bb} --include=\*.{py,sh} "$1" "$PWD"
}}

map Tz push :see

[lmburns]

@kmarius

I got the function I was using to work by doing the following:

cmd trash ${{
  builtin setopt extendedglob
  local MATCH
  local -a arr short
  # Turn into an array
  arr=( "${(f)fx}" )
  # Since brackets are only able to be used once in lf, get tail here
  short=( ${arr:t2})
  rip -- $fx
  dunstify -a lf " Deleted File(s)" "${(F)short}" && {
     print -Prl ${arr//(#m)*/%F{3}%B*%b %F{14}%U$MATCH%u%f: [%F{1}%Bdeleted%f%b]} \
       | hck -d ':' -D $'\t'
  }
}}

I didn't have to use the double brackets, but it is more convenient to be able to. I am unsure if the parser would somehow be able to detect the last bracket in the set by iterating over all characters until it either reaches the end of the file, another function, or a mapping command.

The goal was to turn $fx to an array and get the last two components (:t2) of the path, then join the array with newlines ((F)) to display in a notification. Using quotes may work in bash, but I couldn't get it to work here.

So I would say that this post is more of a feature request rather than a question

[Serkan80]

@lmburns thanks ! That solved my problem. I didn't know about the !{{ ... }} syntax.

And I had solved it by setting my shell into bash with: set shell=bash, then it also works.

[gokcehan]

@lmburns As you are most probably aware, the parser simply takes the string between {{ and }} as a single token. It's a simple approach that work well in most cases, and some other cases can be handled with tweaks as proposed in this issue. Otherwise, you have to assume something about the language that goes inside the command and things can get complicated if not impossible with all the corner cases. In retrospective, maybe I should have used {{{ and }}} instead of {{ and }} to be safer but even then I'm sure we would get some issue reported at some point and I don't think it is worth making a breaking change at this point.

[lmburns]

@gokcehan Alright, I understand. I was mainly just asking whether there was a way around it, to trick the parser into not counting certain brackets. I could've sworn that I had read a way to be able to do that whenever I first started using this file-manager, but I think I am remembering wrong.

I will go ahead and close this issue

[kmarius]

@gokcehan Maybe it is not too late to change the parser so that it consumes all opening {{...{ and takes everything up until the correspondig number of closing }..}}? This would only break current setups where the command begins with { and no space before.

[gokcehan]

@kmarius Actually that sounds quite reasonable. I think that would be an acceptable breaking change if anything. I'm reopening the issue.