in reply to bad interpretor error when running scripts off an NFS share

Check for bad line end characters on the shebang line. A new line character (lf) is expected - a carriage return (cr) or cr/lf pair will cause grief of the nature you describe.

True laziness is hard work
  • Comment on Re: bad interpretor error when running scripts off an NFS share

Replies are listed 'Best First'.
Re^2: bad interpretor error when running scripts off an NFS share
by GaijinPunch (Pilgrim) on Oct 17, 2009 at 10:33 UTC
    Yeah, checked that first. I think copying the file to the machine locally and running it without a hitch is also confirmation that that is not the problem.
[reply]

      Maybe the NFS share is mounted as "noexec"? (I think that would produce the exact error you're getting, whereas some trailing junk char(s) in the shebang line would rather produce "... No such file or directory").

      What does mount show for the share in question?

[reply]
[d/l]
[select]
        YOU WIN! It is indeed mounted as noexec. However, I'm mounting it in fstab, and the options are only 'defaults,user'. I'll google around and see what I'm doing wrong. Cheers for that... and to everyone else that gave their 2 cents worth.
[reply]

      Some ideas to try

      • compare the hex dumps (od -x, hd, xxd, ...) of the first few lines. On the file server locally, "copied" version (how did you copy it?) and accessed-via-nfs.
      • implicit conversion might also be part of the mount options. What OS is the server, what is the client?
      • strace -o log -e file SCRIPTNAME # what files are accessed?
      • strace -o log -e file perl ./SCRIPTNAME # (use cat -vet when viewing the log)

      cu
      Peter

[reply]

        I think strace wouldn't help here (actually this is one of the very few cases where it wouldn't :), as it would only show something like (in case the shebang line is incorrect, that is) 

        execve("./SCRIPTNAME", ["./SCRIPTNAME"], [/* 31 vars */]) = -1 ENOENT 
+(No such file or directory)

        [download]

        The actual shebang resolution happens directly in the kernel, which is invisible to strace-ing.

        Note that the "bad interpreter" info is added by bash (as a hint to the user) in case the file permissions of the script itself etc. are OK, but the execve still does return with an error.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom