4

I am getting a weird error with the mvim script that is supposed to start the MacVim interface.

See below for the issue. /bin/sh is just fine, mvim was chmod +x'd, other /bin/sh scripts run fine... I'm at a loss here.

jan@MacBook-Pro ~ $ file Applications/mvim 
Applications/mvim: POSIX shell script text executable
jan@MacBook-Pro ~ $ head Applications/mvim 
#!/bin/sh
#
# This shell script passes all its arguments to the binary inside the
# MacVim.app application bundle.  If you make links to this script as view,
# gvim, etc., then it will peek at the name used to call it and set options
# appropriately.
#
# Based on a script by Wout Mertens and suggestions from Laurent Bihanic.  This
# version is the fault of Benji Fisher, 16 May 2005 (with modifications by Nico
# Weber and Bjorn Winckler, Aug 13 2007).
jan@MacBook-Pro ~ $ chmod +x Applications/mvim
jan@MacBook-Pro ~ $ Applications/mvim 
-bash: Applications/mvim: /bin/sh: bad interpreter: Operation not permitted

Below you can see that /bin/sh scripts run fine...

jan@MacBook-Pro ~ $ vim test.sh
jan@MacBook-Pro ~ $ chmod +x test.sh 
jan@MacBook-Pro ~ $ ./test.sh 
hi
jan@MacBook-Pro ~ $ cat test.sh 
#!/bin/sh

echo "hi"
Improve this question

2 Answers 2

Reset to default
4

Hmm, so it seems OS X thought it was a good idea to quarantine my script, for some reason, and not tell me about it.

jan@MacBook-Pro ~ $ xattr -d com.apple.quarantine Applications/mvim

fixes the issue.

Improve this answer
-1

I too had a similar problem that was seemingly caused by something different and I just couldn't put my finger on what it was.

This is an edit to my original answer. I have now remove my back and forth attempts to understand the causes. I suggested it was caused by symbolic or hard links that somehow changed due to some file or disk actvity. But all I seemed to do was make the simple solution somewhat confusing.

Regardless of what happened it is an easy fix - just create a new copy. A file copy won't work as that just copies whatever that file had become. Use cat instead.

   $ cat weatherHistory.sh > weatherHistory2.sh
   $ rm weatherHistory.sh
   $ mv weatherHistory2.sh weatherHistory.sh
   $ ./weatherHistory.sh. # Executes as expected

This is on MacOSX 10.14.6.

Improve this answer
11
  • 1
    The @ as part of the permissions doesn‘t indicate a hard link
    – nohillside ♦
    Commented Jan 27, 2020 at 12:04
  • You are right, its a symbolic link. I'll fix the answer.
    – HankCa
    Commented Jan 28, 2020 at 12:40
  • 1
    I think you are mixing this with @ at the end of the filename Maybe have a look at man ls for an explanation of what a @ at the end of the permissions means :-)
    – nohillside ♦
    Commented Jan 28, 2020 at 12:53
  • 1
    From the part of the man page you've quoted: " Display a [...] immediately after each pathname". Your ls output doesn't contain a @ after the pathname though. The relevant part of the man page rather is If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a '@' character.
    – nohillside ♦
    Commented Jan 30, 2020 at 21:20
  • 1
    From what I can see your fix (cat file > newfile) works to resolve whatever issues script had. It isn't related to the use of (symbolic or hard) links though.
    – nohillside ♦
    Commented Jan 30, 2020 at 21:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .