81–90 of 243 posts
These are awesome. I didn't know about many of them. One tiny thing though, at the bottom it says > Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line. Actually, you can launch them in other ways. Example /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/Us…
Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting). The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.
The one utility I can't live without is caffeinate, which prevents a Mac from sleeping. It's super useful for keeping long running tasks running.
Right now I am more interested in creating simple visual interfaces on top of UNIX-y tools, for my own personal use cases. The main benefit of this is the ability to better experiment with and optimize my workflows for different properties as needed through different combinations of single responsibility interfaces and single responsibility programs.
I am sensing that there is great promise in seeing much higher APMs (actions per minute) for many tasks, even compared to the all-powerful command line. Also, there are lots of interesting possibilities for better visual representations of data to improve comprehension and usability.
This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…
> - Install iterm2. The main reason to use it >instead of the default Terminal application is that It just works©. What's wrong with the default Terminal application? I use it daily and have been for close to a decade. I never found myself wishing it did anything than what it already does. > -Use tmux. Meh. For most people screen works just as well. Perhaps more importantly, you can rely on screen being available pre…
These are awesome. I didn't know about many of them. One tiny thing though, at the bottom it says > Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line. Actually, you can launch them in other ways. Example /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/Us…
Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting). The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.
So, doing Foo.app/Contents/MacOS/Foo is often the only way to launch a GUI app while inheriting the full environment that you have on the command line.
I often have to do this to launch various developer tools, and have them be able to inherent important environment variables, e.g. database credentials or secrets,
This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…
export MARKPATH=$HOME/.marks
function jump {
cd -P $MARKPATH/$1 2>/dev/null || echo "No such mark: $1"
}
function mark {
mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1
}
function unmark {
rm -if "$MARKPATH/$1"
}
function marks {
ls -l $MARKPATH | sed 's/ / /g' | cut -d' ' -f9- | sed 's/ -/ -/g' && echo
}
function _marks {
reply=($(ls $MARKPATH))
}
compctl -K _marks jump
compctl -K _marks unmark
% mark
% jump
% marks
no love for macport?
This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…
Don't need symlinks. Just set the CDPATH environment variable! Also set up case insensitive completion, saves the extra shift press for all those Mac paths.
This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…
> Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code. This is an excellent point and one that's not nearly as appreciated as it should be. Fullscreen mode was written off in Lion as an example of Apple dumbing down the platform and making it more like…
Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free version is fully functional with just an occasional nag screen.