paraview setup issue

[AleksZhuravlyov]

paraview setup file apparently should be patched as follows:

--- a/etc/config.sh/mac/paraview
+++ b/etc/config.sh/mac/paraview
@@ -8,7 +8,7 @@ then
         $_paraviews/Contents/MacOS/paraview "$@"
     }

-    export -f paraview
+    export paraview
 else
     echo
     echo "Please download binary Paraview release from"

[mrklein]

Could you post versions of your OS and shell? Current solution works fine with 11.0.1 and bash 3.2.57.

[AleksZhuravlyov]

Could you post versions of your OS and shell? Current solution works fine with 11.0.1 and bash 3.2.57.

OS version is 10.15.7 and I use zsh 5.8.

The unwanted behavior of export -f paraview in zsh is a print in terminal of the function content as below:

paraview () {
    local _paraviews=(/Applications/[Pp][Aa][Rr][Aa][Vv][Ii][Ee][Ww]*.app) 
    $_paraviews/Contents/MacOS/paraview "$@"
}

I have tested it with bash 3.2.57 and such a print is absent. looks like it's a zsh issue.

-f points that a function is exported, but without -f it works properly in zsh as well as in bash.

[mrklein]

Well, not quite. I did not check documentation of zsh, for bash

The supplied names are marked for automatic export to the
environment of subsequently executed commands.  If the -f
option is given, the names refer to functions.

So, if we execute paraview in current shell, it OK. If we try to execute paraview in a sub-shell, it will fail.

Consider simple test.sh:

#!/bin/bash

paraview

with export -f paraview everything works as expected (ParaView is launched), while without -f flag output is:

$ ./test.sh 
./test.sh: line 3: paraview: command not found

There are also another use cases, when export without -f does not work.

IIRC the reason behind switch to function and export -f was to support sub-shells. In Bernhard Gschaider's patches paraview was implemented as an alias, which did not work for non-interactive shells.

Also the idea behind alias or function was to avoid adding paraview command to PATH variable, as in this case there were problems with Python scripting. Maybe this problem was resolved long time ago, I did not check, as I do not do any serious Python scripting inside ParaView.

[AleksZhuravlyov]

Well, not quite. I did not check documentation of zsh, for bash

The supplied names are marked for automatic export to the
environment of subsequently executed commands.  If the -f
option is given, the names refer to functions.

So, if we execute paraview in current shell, it OK. If we try to execute paraview in a sub-shell, it will fail.

Consider simple test.sh:

#!/bin/bash

paraview

with export -f paraview everything works as expected (ParaView is launched), while without -f flag output is:

$ ./test.sh 
./test.sh: line 3: paraview: command not found

There are also another use cases, when export without -f does not work.

IIRC the reason behind switch to function and export -f was to support sub-shells. In Bernhard Gschaider's patches paraview was implemented as an alias, which did not work for non-interactive shells.

Also the idea behind alias or function was to avoid adding paraview command to PATH variable, as in this case there were problems with Python scripting. Maybe this problem was resolved long time ago, I did not check, as I do not do any serious Python scripting inside ParaView.

Thank you for clarification.