Can't run normal bash functions inside clifm.

[LinArcX]

OS: VoidLinux
Clifm: v1.17

I have a lot of functions inside my .bashrc that rely heavily on fzf. they're working pretty well inside Bash. But as soon as I try to run them inside clifm, i will get this error:
clifm: xterm: Command not found

Here is one of them:

x() {
  commands=("update" "install" "search" "xlocate"
    "apps" "apps(sorted by installed-date)"
    "pkgs (local)" "pkgs (repo)" "pkg files" "pkg deps" "pkg rev-deps" "pkg rev-deps number" "pkg req-deps" "orphaned pkgs" "hold pkgs" "manaual pkgs" "nonfree pkgs"
    "remove" "xpurge" "remove orphans & obsolete" "remove old kernels" "remove orphaned pkgs" "remove obsolete pkgs"
    "repos" "kernels" "dry-run" "cache size" "pkgs cache number")

  selected=$(printf '%s\n' "${commands[@]}" | fzf --header="xbps:" --preview 'v {}')
  case $selected in
    "update")
      echo "xu is more handy, isn't it?";;
    "install")
      echo "xi is more handy, isn't it?";;
      #read -p "install: " package_name; sudo xbps-install -S $package_name ;;
      ;;
  esac
}

The point is that those functions populate a list of items and show them in fzf. maybe because they try to show fzf inside clifm this problem happens?

This is when i run x() in bash:

[LinArcX]

I tried to make things simpler. so look at this sample commands:

commands=("hi" "bye")
selected=$(printf '%s\n' "${commands[@]}" | fzf )

There are two weird things happening:

1. echo $commands in bash prints: hi, but inside clifm prints nothing.
2. selected=$(printf '%s\n' "${commands[@]}" | fzf ) shows the menu with items properly in bash but it's empty in clifm.

Probably you're processing the user input each time and maybe it conflict with bash command processing?

[leo-arch]

Clifm knows nothing about functions. To make it understand even a simple function means to make it understand a scripting language (POSIX sh at the very least). But no, clifm is not a shell (and will never be it), but a file manager.

However, as you know, everything's possible. I'm pretty sure your shell functions can be easily transformed into a proper shell script, which, located somewhere in your PATH, can be called/executed from within clifm as every other command. You can even create an alias for it, or make it into a plugin.

[LinArcX]

oh, wow! i'm surprised.

Because i was thinking when i dropped into clifm, it will sit on top of my current shell + some additional commands that it provides.

I don't want to interfere with design decisions, but i think it makes more sense in this way.

imagine for any function we need to create an alias or seprate plugin. that's time consuming.

anyway. thanks for clearification.

[LinArcX]

i didn't expect clifm to be shell. because you have your shell already! i was expecting a layer on top of my shell.

something like:
https://github.com/akinomyoga/ble.sh
or
https://github.com/chrisant996/clink

[leo-arch]

Because i was thinking when i dropped into clifm, it will sit on top of my current shell + some additional commands that it provides.

Clifm does sit on top the you current shell, in the sense that, as any other program, it is executed from you shell. To run shell commands, and this includes all shell goodies, we run a new instance of the shell passing to it the command to be executed. In other words, running a shell command in clifm is like running sh -c 'CMD'. If you command does not work in this way, it won't work on clifm either.

I don't want to interfere with design decisions, but i think it makes more sense in this way.

Maybe. This is why I always insist on this point: clifm is a file manager based on the command line, which, besides, can run shell commands, as explained above (but this does not mean that it can access every feature/function provided by the underlying shell).

imagine for any function we need to create an alias or seprate plugin. that's time consuming.

Absolutely true.

[leo-arch]

Btw, would it be possible to make clifm (or some similar program) into a real bash extension? No doubt. But in this case the program would be just that, a bash extension (limited as such to the bash shell), and not an independent program which, as such, can run on any shell (and even without a shell). This is the price we have to pay I guess.