Skip to main content
replaced http://apple.stackexchange.com/ with https://apple.stackexchange.com/
Source Link

To prefer Terminal to open .sh files — using the defaults command, without using Finder

In most cases, all that's required should be possible from the command line …

Preparation

Two commands:

defaults read com.apple.LaunchServices | grep -B 1 -A 3 public.shell-script

defaults read com.apple.LaunchServices | grep -B 1 -A 4 "LSHandlerContentTag = sh;"

If either command reveals an existing preference

Use Xcode or any other suitable property list editor to remove the relevant dictionary from the LSHandlers key within the following file:

~/Library/Preferences/com.apple.LaunchServices.plist

Hints:


Adding to LaunchServices preferences, for Terminal to view and edit .sh files

Two one-line commands.

Depending on your requirements, the first command alone may suffice:

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentType = "public.shell-script"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentTag = "sh"; LSHandlerContentTagClass = "public.filename-extension"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

For the new preferences to be respected

Modifications to the user domain persistence layer of Launch Services must be acknowledgedModifications to the user domain persistence layer of Launch Services must be acknowledged. For this, least disruptive to the end user will be:

  • a restart of the operating system.

From the command line, if immediate restart is acceptable:

sudo shutdown -r now


Background

Understanding Terminal.app support for .sh (public.shell-script)

Consider the result of the following command:

defaults read /Applications/Utilities/Terminal.app/Contents/Info

Terminal aside for a moment: it's sometimes inappropriate (or simply worthless) to force opening of a document type, by an app that is designed without support for that type.

For Terminal, I imagine no harm in handling the public.shell-script type.

To prefer Terminal to open .sh files — using the defaults command, without using Finder

In most cases, all that's required should be possible from the command line …

Preparation

Two commands:

defaults read com.apple.LaunchServices | grep -B 1 -A 3 public.shell-script

defaults read com.apple.LaunchServices | grep -B 1 -A 4 "LSHandlerContentTag = sh;"

If either command reveals an existing preference

Use Xcode or any other suitable property list editor to remove the relevant dictionary from the LSHandlers key within the following file:

~/Library/Preferences/com.apple.LaunchServices.plist

Hints:


Adding to LaunchServices preferences, for Terminal to view and edit .sh files

Two one-line commands.

Depending on your requirements, the first command alone may suffice:

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentType = "public.shell-script"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentTag = "sh"; LSHandlerContentTagClass = "public.filename-extension"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

For the new preferences to be respected

Modifications to the user domain persistence layer of Launch Services must be acknowledged. For this, least disruptive to the end user will be:

  • a restart of the operating system.

From the command line, if immediate restart is acceptable:

sudo shutdown -r now


Background

Understanding Terminal.app support for .sh (public.shell-script)

Consider the result of the following command:

defaults read /Applications/Utilities/Terminal.app/Contents/Info

Terminal aside for a moment: it's sometimes inappropriate (or simply worthless) to force opening of a document type, by an app that is designed without support for that type.

For Terminal, I imagine no harm in handling the public.shell-script type.

To prefer Terminal to open .sh files — using the defaults command, without using Finder

In most cases, all that's required should be possible from the command line …

Preparation

Two commands:

defaults read com.apple.LaunchServices | grep -B 1 -A 3 public.shell-script

defaults read com.apple.LaunchServices | grep -B 1 -A 4 "LSHandlerContentTag = sh;"

If either command reveals an existing preference

Use Xcode or any other suitable property list editor to remove the relevant dictionary from the LSHandlers key within the following file:

~/Library/Preferences/com.apple.LaunchServices.plist

Hints:


Adding to LaunchServices preferences, for Terminal to view and edit .sh files

Two one-line commands.

Depending on your requirements, the first command alone may suffice:

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentType = "public.shell-script"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

defaults write com.apple.LaunchServices LSHandlers -array-add '{ LSHandlerContentTag = "sh"; LSHandlerContentTagClass = "public.filename-extension"; LSHandlerRoleViewer = "com.apple.Terminal"; LSHandlerRoleEditor = "com.apple.Terminal"; }'

For the new preferences to be respected

Modifications to the user domain persistence layer of Launch Services must be acknowledged. For this, least disruptive to the end user will be:

  • a restart of the operating system.

From the command line, if immediate restart is acceptable:

sudo shutdown -r now


Background

Understanding Terminal.app support for .sh (public.shell-script)

Consider the result of the following command:

defaults read /Applications/Utilities/Terminal.app/Contents/Info

Terminal aside for a moment: it's sometimes inappropriate (or simply worthless) to force opening of a document type, by an app that is designed without support for that type.

For Terminal, I imagine no harm in handling the public.shell-script type.

replaced http://superuser.com/ with https://superuser.com/
Source Link
Credit to @kopischke for his accepted answer under 'Why is a command line change to ~/Library/Preferences/com.apple.LaunchServices.plist not effective immediately?'.
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
 

 

First attempt, an experiment

After editing the Modifications to the user domain persistence layer of Launch Services must be acknowledged.plist I tried logging out of the system For this, then logging in. This did not have the desired effect.

Second attempt

Maybe not the best approach for modern releases ofleast disruptive to the system, these two commands seem effectiveend user will be:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -seed -v

  • option -v only if you want a verbose viewrestart of progressthe operating system.

After the scan completes — afterFrom the Launch Services database has been seeded — you should find that .sh files open in Terminal in response to an open command.

Probably best

The accepted answer to Super User question Is there a faster way to change default apps associated with file types on OS X? suggests line, if immediate restart is acceptable:

… restarting the OS to apply changes (logging out and back in isn't enough) …

This grey area leads to a new question —

Why is a command line change to ~/Library/Preferences/com.apple.LaunchServices.plist not effective immediately?

An accepted answer to that question should allow us to refine answers here.sudo shutdown -r now


 

First attempt, an experiment

After editing the .plist I tried logging out of the system, then logging in. This did not have the desired effect.

Second attempt

Maybe not the best approach for modern releases of the system, these two commands seem effective:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -seed -v

  • option -v only if you want a verbose view of progress.

After the scan completes — after the Launch Services database has been seeded — you should find that .sh files open in Terminal in response to an open command.

Probably best

The accepted answer to Super User question Is there a faster way to change default apps associated with file types on OS X? suggests:

… restarting the OS to apply changes (logging out and back in isn't enough) …

This grey area leads to a new question —

Why is a command line change to ~/Library/Preferences/com.apple.LaunchServices.plist not effective immediately?

An accepted answer to that question should allow us to refine answers here.

 

Modifications to the user domain persistence layer of Launch Services must be acknowledged. For this, least disruptive to the end user will be:

  • a restart of the operating system.

From the command line, if immediate restart is acceptable:

sudo shutdown -r now

Bounty Ended with 50 reputation awarded by bmike
Clearer title, clearer separation between key sections of the answer, more prominence to my related question (aiming to refine this answer).
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Greater prominence to the Super User answer from Daniel Beck, which now includes a neat script :-)
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Grammar.
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Link to a new, related question.
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Better heading. Credit to Daniel Beck for his answer in Super User. For this Ask Different question, I took a closer look at Terminal (and remain puzzled why logging out was insufficient for edited preferences to become effective.)
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Minor improvement to the subsection about Terminal support for public.shell-script
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading
Source Link
Graham Perrin
  • 7.8k
  • 14
  • 83
  • 246
Loading