-
Notifications
You must be signed in to change notification settings - Fork 19
Command line for OSX
Shoes 3.2.24 introduced a way to make working from the OSX command line much easier, similar in concept to what Shoes 3.2 did for Windows. OSX now has a cshoes - it's just a bash script that knows how to start Shoes in a command line friendly way. All the -switches work (although --ruby has some oddness). It's a ugly little script but its pretty useful.
For OSX reasons, the absolute path to Shoes.app has to be hard coded into the script but we can hide that. Mostly. There are two ways to get the cshoes script depending on whether you build from source or you just download a Shoes/OSX binary and install that.
If you build Shoes from source, the cshoes script is created in the top dir (where you issued the rake) every time you build Shoes and the script points to where ever your newly built Shoes lives. That is not /Applications
or ~/Applications
You create/modify the mavericks-custom.yaml if needed. You issue a 'rake' and then you can do something like ./cshoes -g list -l
or ./cshoes samples/simple-info.rb
The rake file just does a rewrite of the cshoes.tmpl script in platforms/mac/
If you go the binary route, Shoes 3.2 doesn't really have an installer for OSX. You'll have to generate the script yourself - that's easy because there is Cobbler (Maintain Shoes) button.
That example uses the Shoes I downloaded and expanded in my Downloads folder. Normal people would probably drag Shoes to /Applications
and not run Shoes from ~/Downloads. Assume you dragged Shoes to /Applications. Then a clever person would drag the created cshoes script to /usr/local/bin but you already figured that out.
What could go wrong? Since you can create as many cshoes as you like and place them all over you directories and they are hard-coded to where you installed Shoes, if you decide to move Shoes later, then all those old cshoes scripts will not work. Of course, if you put cshoes in /usr/local/bin and it pointed to /Applications/Shoes.app then you'd only have one copy that worked in all your projects. As a command line commando you knew that.
Update: 2016-06-22
The script above was minimal. In 3.3.2 we will have one that is better, in many ways. For one, it doesn't use open
which means that the Shoes app is attached to the launching terminal so STDOUT and STDERR still work. This is useful for some scriptwriters and much more like Linux and Windows. It also parses the command line more intelligently before calling Shoes. That said, bash is not a language I know well and delays on Shoes 3.3.2 are large. Here's a listing you might find useful
#!/bin/sh
# next two lines generated
APPPATH="/Users/ccoupe/build/xmavericks/Shoes.app/Contents/MacOS"
SHOES_RUBY_ARCH="x86_64-darwin14"
THISDIR=`pwd`
FLAGS=""
SCRIPT=""
OPTIND=1
if [ "$1" = "--ruby" ] || [ $1 == '-g' ] || [ $1 == '--gem' ] ; then
FLAGS=$@
else
while getopts "w:f:e:ghv" opt; do
case "$opt" in
h) FLAGS="-h" ;;
v) FLAGS="-v" ;;
w) SCRIPT=$OPTARG; FLAGS="-w" ;;
f) SCRIPT=$OPTARG; FLAGS="-f" ;;
e) SCRIPT=$OPTARG; FLAGS="-e" ;;
esac
done
shift $((OPTIND-1))
if [[ -n $1 ]]; then
#echo "found " $1
SCRIPT=$1
if [[ -z $FLAGS ]] ; then
FLAGS='-f' # consider this a hack until shoes.rb is fixed for OSX
fi
fi
if [[ -n $SCRIPT ]] && (! [[ $SCRIPT =~ ^/.* ]]); then
SCRIPT="$THISDIR/$SCRIPT"
fi
fi
echo "using shoes-bin $FLAGS $SCRIPT"
unset DYLD_LIBRARY_PATH
DYLD_LIBRARY_PATH="$APPPATH" PANGO_RC_FILE="$APPPATH/pangorc" SHOES_RUBY_ARCH="$SHOES_RUBY_ARCH" $APPPATH/shoes-bin $FLAGS $SCRIPT
To use on your OSX installation of Shoes just change that APPPATH location. The final script will be slightly different, of course. And you can write your own if you don't like this one. I call it tshoes
for now.