I do have to send a report regarding pasting some clipboard content into a web rich editor and I need a way to dump/restore the clipboard content to (probably) HTML.
How can I do this?
It seems that pbcopy / pbpaste do alway give me text even if I use the pbpaste -P rtf or pbpaste -P HTML
Three years later, in more civilized times, we have Swift. You can write a short Swift script to pull exactly what you need off of OS X's pasteboard.
Put the following Swift 4 snippet into a new text file. I named mine pbpaste.swift:
import Cocoa
let type = NSPasteboard.PasteboardType.html
if let string = NSPasteboard.general.string(forType:type) {
print(string)
}
else {
print("Could not find string data of type '\(type)' on the system pasteboard")
exit(1)
}
Then, copy some html, and run swift pbpaste.swift from the directory where you put that file.
Yay, html! Uggh, OS X added a ton of custom markup (and a <meta> tag?!) — but hey, at least it's not plain text!
Notes:
NSPasteboard.PasteboardType.html is a special global that evaluates to the string "public.html"
Obviously this is html specific, so you'd probably want to either:
Name it pbpaste-html.swift, or
Read the desired type from the command line arguments
It's kind of slow, because it's being interpreted on the fly, not compiled and executed. Compilation gives me a 10x speed-up:
xcrun -sdk macosx swiftc pbpaste.swift -o pbpaste-html
Then just call ./pbpaste-html instead of swift pbpaste.swift.
I realise you've already found this, but for the benefit of people who turn up here from Google, the solution given for RTF data at Getting RTF data out of Mac OS X pasteboard (clipboard) works fine for getting HTML out of the clipboard, too.
That is, the command
osascript -e 'the clipboard as «class HTML»' | perl -ne 'print chr foreach unpack("C*",pack("H*",substr($_,11,-3)))'
Related
I'm trying to localize my app, and I have the following code:
self.arrayLabels = [NSArray arrayWithObjects:NSLocalizedString(#"This is a test", "this is a test"), NSLocalizedString(#"I want my strings to get added to localizable strings file", "strings comment") , nil];
So, basically, from what I understand, this should be it, I click Editor > Export for Localization and the strings should be there on my XLiff file. But, they aren't.
I have two languages, english and portuguese, both localizable.strings files are empty.
Am I missing something?
I discovered that I had a few errors and that is why I could not export from the menu.
I suspect that the error messages are not being returned.
It turns out that the menu is calling existing command line tools so by a process of elimination you may be able to fix your export.
Here are the steps I took to fix my issues. Hopefully they will help you.
Run the command line equivalent
xcodebuild -exportLocalizations
If you have errors xcodebuild may give file names and line numbers so you should be able to fix the issues.
I had one error that did not have any details.
I then switched to using genstrings as that is what xcodebuild appears to be using in a loop.
find . -name '*.m' | xargs genstrings -o somePath/en.lproj
this gave the same error
To get the file with the problem I ran each file separately in a loop.
for f in `find . -name '*.m'`; do
echo "processing $f ...";
genstrings -o somePath/en.lproj $f
done
That gave me the name of the file that had an issue.
It turned out that genstrings did not like a special character I was trying to print using a unicode character \U000000B2.
For the exported XLIFF to contain your localized strings, a few conditions have to be met:
The keys must be present in your localized strings file. In your case these files are empty. Which will explain the problem.
You must use the keys as string literal with the NSLocalizedString macro. For example:
This is the correct way:
NSLocalizedString("some_key", "")
This will not work:
let key = "some_key"
NSLocalizedString(key, "")
In Xcode, use the Editor-->"Extract for Localization" menu which will generate the .xliff files (one per language selected). The .xliff files are sent to a translation service for translation. Once the .xliff files are updated by the translation service, you need to import it back into the app using Editor-->"Import Localizations". Once this step is done, for each language, you will find a xx.lproj/ folder with the results of the translation.
I would like to determine the OS X keyboard layout (or "input source" as OS X calls it) from the terminal so that I can show it in places like the tmux status bar.
So I want to know if the current layout is "U.S." or "Swedish - Pro" for example.
Googling turns up nothing for me. Is this possible?
Note: #MarkSetchell deserves credit for coming up with the fundamental approach - where to [start to] look and what tools to use.
After further investigation and back and forth in the comments I thought I'd summarize the solution (as of OS X 10.9.1):
do shell script "defaults read ~/Library/Preferences/com.apple.HIToolbox.plist \\
AppleSelectedInputSources | \\
egrep -w 'KeyboardLayout Name' | sed -E 's/^.+ = \"?([^\"]+)\"?;$/\\1/'"
Note how \ is escaped as \\ for the benefit of AppleScript, which ensures that just \ reaches the shell. If you want to execute the same command directly from the shell (as one line), it would be:
defaults read ~/Library/Preferences/com.apple.HIToolbox.plist AppleSelectedInputSources | egrep -w 'KeyboardLayout Name' |sed -E 's/^.+ = \"?([^\"]+)\"?;$/\1/'
The currently selected keyboard layout is stored in the user-level file ~/Library/Preferences/com.apple.HIToolbox.plist, top-level key AppleSelectedInputSources, subkey KeyboardLayout Name.
defaults read ensures that the current settings are read (sadly, as of OSX 10.9, the otherwise superior /usr/libexec/PlistBuddy sees only a cached version, which may be out of sync).
Since defaults read cannot return an individual key's value, the value of interest must be extracted via egrep and sed - one caveat there is that defaults read conditionally uses double quotes around key names and string values, depending on whether they are a single word (without punctuation) or not.
Update:
Turns out that AppleScript itself can parse property lists, but it's a bit like pulling teeth.
Also, incredibly, the potentially-not-fully-current-values problem also affects AppleScript's parsing.
Below is an AppleScript handler that gets the current keyboard layout; it uses a do shell script-based workaround to ensure that the plist file is current, but otherwise uses AppleScript's property-list features, via the Property List Suite of application System Events.
Note: Obviously, the above shell-based approach is much shorter in this case, but the code below demonstrates general techniques for working with property lists.
# Example call.
set activeKbdLayout to my getActiveKeyboardLayout() # ->, e.g., "U.S."
on getActiveKeyboardLayout()
# Surprisingly, using POSIX-style paths (even with '~') works with
# the `property list file` type.
set plistPath to "~/Library/Preferences/com.apple.HIToolbox.plist"
# !! First, ensure that the plist cache is flushed and that the
# !! *.plist file contains the current value; simply executing
# !! `default read` against the file - even with a dummy
# !! key - does that.
try
do shell script "defaults read " & plistPath & " dummy"
end try
tell application "System Events"
repeat with pli in property list items of ¬
property list item "AppleSelectedInputSources" of ¬
property list file plistPath
# Look for (first) entry with key "KeyboardLayout Name" and return
# its value.
# Note: Not all entries may have a 'KeyboardLayout Name' key,
# so we must ignore errors.
try
return value of property list item "KeyboardLayout Name" of pli
end try
end repeat
end tell
end getActiveKeyboardLayout
Recently I had written a small console utility (https://github.com/myshov/xkbswitch-macosx) on Objective-C to do this. It's a lot faster than a script based solutions. It can to get the current input layout but also it can to set the given input layout.
To get a current layout:
$xkbswitch -ge
> US
To set a given layout:
$xkbswith -se Russian
I am not sure of this answer, but it may be worth checking out. If you look in file:
/Library/Preferences/com.apple.HIToolbox.plist
there is a variable called
AppleCurrentKeyboardLayoutSourceID
and mine is set to "British" and I am in Britain...
You can read the file in a script with:
defaults read /Library/Preferences/com.apple.HIToolbox.plist AppleEnabledInputSources
sample output below:
(
{
InputSourceKind = "Keyboard Layout";
"KeyboardLayout ID" = 2;
"KeyboardLayout Name" = British;
}
)
So, I guess your question can be simply answered using this:
#!/bin/bash
defaults read /Library/Preferences/com.apple.HIToolbox.plist AppleEnabledInputSources | grep -sq Swedish
[[ $? -eq 0 ]] && echo Swedish
This question led to the creation of the keyboardSwitcher CLI Tool:
https://github.com/Lutzifer/keyboardSwitcher
Though similar to the already mentioned https://github.com/myshov/xkbswitch-macosx this has additional features, e.g. the list of Layouts is not hardcoded and thus can also support third party layouts (e.g. Logitech) and supports installation via homebrew.
Figured out how to do it with AppleScript, assuming you have the menu bar input menu.
Run this in a terminal:
osascript -e 'tell application "System Events" to tell process "SystemUIServer" to get the value of the first menu bar item of menu bar 1 whose description is "text input"'
Works fine even if you only show the input menu as flag icons, without the input source name.
Mavericks will probably prompt you to allow access, the first time. In earlier versions of OS X I suspect you'll need to turn on support for assistive devices in your accessibility preferences.
I was searching for an answer to an issue I was having with the keyboard layout that lead me to this post. I found the solution for my problem here.
Resolved Issues
You might experience difficulty logging into your account because the keyboard layout may change unexpectedly at the
Login window. (40821875)
Workaround: Log in to your account, launch Terminal, and execute the
following command:
sudo rm -rf /var/db/securityagent/Library/Preferences/com.apple.HIToolbox.plist
This is an Apple official release note for Mojave
I need to share information from a plist with someone who is not technically inclined. Is there a common free editor that one can use to view plist info in a similar way in which it is presented in Xcode? Or is there a way to print it out?
In other words I would like to view the plist without all the xml-like mark up and without the use of Xcode.
Command-line options for viewing Plist files:
For viewing only: Use plutil -p, which prints the content of a property-list in JSON-like format (the format is meant for human consumption only).
Example (append | open -tf to view output in a text editor):
plutil -p ~/Library/Preferences/com.apple.sidebarlists.plist
Alternative: Use /usr/libexec/PlistBuddy -c print, which outputs in JavaScript-object-literal-like format:
Example:
/usr/libexec/PlistBuddy -c print ~/Library/Preferences/com.apple.airplay.plist
Caveat:
If the plist has properties containing binary data, PlistBuddy will include it in raw form (by contrast, non-binary properties in the same file are printed properly). If XML output is desired, add option -x.
Note that PlistBuddy:
can be used to extract properties selectively using :-separated, case-sensitive property paths; e.g., /usr/libexec/PlistBuddy -c 'print :favorites:ShowRemovable' ~/Library/Preferences/com.apple.sidebarlists.plist
is also capable of modifying Plist files from the command line (including, with limitations, importing from previously exported-to XML files).
See /usr/libexec/PlistBuddy -h for details.
The standalone "Property List Editor" is gone since Xcode 4, you can use Pref Setter which is free but last updated 4 years ago.
To save the contents without the xml tags see this example:
NSDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:[#"~/Library/Preferences/loginwindow.plist" stringByExpandingTildeInPath]];
[[dict description] writeToURL:[NSURL fileURLWithPath:[#"~/Desktop/loginwindow.txt" stringByExpandingTildeInPath]] atomically:YES encoding:NSUTF8StringEncoding error:nil];
You can use visual studio code to open and edit Plist files.
Just need to install an extension in the visual studio code called Binary Plist:
Binary Plist
Publisher: David Nicolson
Marketplace Link: https://marketplace.visualstudio.com/items?itemName=dnicolson.binary-plist
There is a way to get the old Property List Editor working on Mac OS X Lion, if you don't want to use bloated XCode 4 for this.
There is a "Property List Editor" app as part of OS X (or there used to be, I'm away from my machine at the moment so can't check).
Failing that, you could write one in about half an hour!
I've been playing with a script that takes the selected text in Chrome and looks it up in Google, offering the four top choices, and then pasting the relevant link. It is pasted in different formats depending on which page is currently open in Chrome - DokuWiki format with DokuWiki open, HTML with normal websites, and I want rich text for my WordPress WYSIWYG editor.
I tried to use pbpaste -Prefer rtf to see what a rich-text link with no other styling looked like on the pasteboard, but it still outputs plain text. After saving a file in Text Edit, and experimenting, I came up with the following
text = %q|{\rtf1{\field{\*\fldinst{HYPERLINK "URL"}}{\fldrslt TEXT}}}|
text.gsub!("URL", url)
text.gsub!("TEXT", stext)
(I had to use the gsub, because somehow when using %Q and #{} to insert the variables, the string didn't work)
This works, however, when I paste it, there is an additional lineshift before and after the link. What would the string look like to avoid this?
From the shell the clean solution is this:
URL="http://www.google.com/"
NAME="Click here for Google"
echo "<a href='$URL'>$NAME</a>" | textutil -stdin -format html -convert rtf -stdout | pbcopy
So, use the textutil command to convert correct html .. into rtf...
ruby variant:
url = 'http://www.google.com'
name = 'click here'
system("echo '#{name}' | textutil -stdin -format html -convert rtf -stdout | pbcopy")
so, when you run the above without pbcopy part, you'll get:
{\rtf1\ansi\ansicpg1250\cocoartf1038\cocoasubrtf350
{\fonttbl\f0\froman\fcharset0 Times-Roman;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue238;}
\deftab720
\pard\pardeftab720\ql\qnatural
{\field{\*\fldinst{HYPERLINK "http://www.google.com/"}}{\fldrslt
\f0\fs24 \cf2 \ul \ulc2 click here}}}
EDIT: Just tested this on BigSur and working as should. Any HTML is got converted to rtf. Another demo (without variables)
echo '<b>BOLD TEXT</b><br>stackoverflow link<br><h1>big title</h1>' | textutil -stdin -format html -convert rtf -stdout | pbcopy
after pasting into TextEdit yields
One way of doing this is using MacRuby, which is able to directly access the pasteboard through the Cocoa framework, rather than using the command line tool, which gives you more options.
For example, you can use this function to paste in HTML code, including hyperlinks, which will function correctly inserted into TextEdit or a WordPress editing box:
framework 'Cocoa'
def pbcopy(string)
pasteBoard = NSPasteboard.generalPasteboard
pasteBoard.declareTypes([NSHTMLPboardType], owner: nil)
pasteBoard.setString(string, forType: NSHTMLPboardType)
end
This works much better than the command-line pbcopy, in that it definitively avoids adding white-space, and also avoids having to send RTF for rich text, where HTML is much easier to generate programmatically.
macOS's pbcopy command can detect RTF. The following example (using pandoc to convert markdown to RTF), places a rich text snippet in your paste buffer:
echo '**foo**' | pandoc -t rtf -s | pbcopy
I made an application that parse the iTunes library to retrieve its content. It works fine in most cases but if a user moved his library somewhere else than the default iTunes folder (see: http://lifehacker.com/238296/ultranewb--how-to-move-your-itunes-library-to-an-external-drive), then I need a way to find this path.
On Mac, I was looking into ~/Library/Preferences/com.apple.iTunes.plist. There is a setting called "alis:1:iTunes Library Location" but it contains several parameters all concatenated and converted to hexadecimal.
On Windows, I found this file "C:\Documents and Settings\\Application Data\Apple Computer\iTunes\iTunesPrefs.xml" that contains a setting "iTunes Library XML Location:1" but this one is encoded.
Any help would be greatly appreciated.
Thanks!
On Windows, the iTunes Library XML Location:1 entry in iTunesPrefs.xml is a Base 64 encoded Unicode string, so you'll need to decode it before you can use it. On my PC, it decodes to C:\Documents and Settings\Emerick\My Documents\My Music\iTunes\iTunes Music Library.xml.
It should be relatively easy to decode this value using your language of choice; your platform may even provide utility libraries that make this trivial. In C#, for example, the decoding function would look something like this:
static public string DecodeBase64(string encodedData)
{
byte[] encodedBytes = System.Convert.FromBase64String(encodedData);
return System.Text.UnicodeEncoding.Unicode.GetString(encodedBytes);
}
I can't help you with the Windows stuff, but on the Mac what you're seeing in that prefs file is old-school alias handle data. Take a look at or just use Chris Hanson's BDAlias class to convert it to a path.
http://github.com/rentzsch/bdalias
As the others point out "alis:1:iTunes Library Location" is alias data. Here's how I find the path from the data in OS X using Python.
#!/usr/bin/env python
import commands, plistlib
from Carbon import File
from os.path import expanduser
PLIST_PATH = '~/Library/Preferences/com.apple.iTunes.plist'
PLIST_KEY = 'alis:1:iTunes Library Location'
def resolve_path_from_alias_data( alis ):
fs_ref = File.Alias( rawdata=alis ).FSResolveAlias( None )[0]
file_path = fs_ref.as_pathname()
return file_path
plist_str = commands.getoutput( '/usr/bin/plutil -convert xml1 -o - "' + expanduser( PLIST_PATH ) + '"' )
plist_data = plistlib.readPlistFromString( plist_str )
alis_data = plist_data[ PLIST_KEY ].data
file_path = resolve_path_from_alias_data( alis_data )
print repr( file_path )
Unfortunately, iTunes no longer uses "alis:1:iTunes Library Location" so this no longer works. Now iTunes 11 uses an entry called "RDoc:132:Documents" which seems to be completely different. I have posted a similar question with the appropriate iTunes 11 details.
Actually, my answer works just fine as of OS X 10.9.1. I'm not sure whether it stopped due to some error I made, or if Apple quietly reverted something. Either way, it's working again on my Mac.