ksh93 ENOEXEC errors solved
If you have been following my blogs on transitioning to an OpenSolaris SPARC based Sun Ray server (part 1 and part 2) you would have seen my frustration at the errors I was getting like:
make: sh: cannot execute [Exec format error] make: sh: cannot execute [Exec format error] make: sh: cannot execute [Exec format error] sh: make: function not defined *** Error code 126
I did some poking around today. I noticed that the stack in the writing of that error message looked like:
libc.so.1`__write+0x8
libast.so.1`_sfflsbuf+0x24c
libast.so.1`sfwrite+0x3e0
libast.so.1`errorv+0xc34
libast.so.1`errormsg+0x1c
libshell.so.1`sh_lex+0x408
libshell.so.1`term+0x34
libshell.so.1`list+0x8
libshell.so.1`sh_cmd+0x18
libshell.so.1`sh_parse+0x2c0
libshell.so.1`sh_eval+0x1c8
libshell.so.1`funload+0x188
libshell.so.1`path_absolute+0x584
libshell.so.1`path_search+0x2b4
libshell.so.1`sh_exec+0xddc
libshell.so.1`sh_subshell+0x5c8
libshell.so.1`comsubst+0x998
libshell.so.1`varsub+0x4f8
libshell.so.1`copyto+0x8dc
libshell.so.1`sh_mactrim+0x10c
It’s trying to treat make as if it were a shell function. Huh? of course that’s not going to work.
Inside path_absolute in libshell I found the following:
767 isfun = (pp->flags&PATH_FPATH);
Further down this is checked and if it is, the file is opened to be read as a shell script.
ding!
Heading to the man page we see:
FPATH The search path for function definitions. The
directories in this path are searched for a
file with the same name as the function or
command when a function with the -u attribute
is referenced and when a command is not found.
If an executable file with the name of that
command is found, then it is read and executed
in the current environment. Unlike PATH, the
current directory must be represented expli-
citly by dot (.) rather than by adjacent colon
(:) characters or a beginning or ending colon
(:).
Now if I add in the fact that I construct my $PATH using $FPATH and $LPATH (among others) a light begins to dawn.
My $FPATH actually contained almost the entirety of my normal path. So, ksh93 (which is also /bin/sh on OpenSolaris) was assuming that anything in any of those directories was a script to be read and parsed, without having to check.
I changed the names of those variables and everything there is now working as it should.
