Live data from Hacker News

OS X Command Line Utilities

mitchchn.me

171–180 of 243 posts

Re: OS X Command Line Utilities

#171
post #86
post #29

Earlier quoted context omitted.

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.

But the open command doesn't allow you to pass the environment, and Apple seems hellbent on breaking every workaround they've implemented over the years (e.g. ~/.MacOSX/environment.plist). 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 abl…

> But the open command doesn't allow you to pass the environment

Uh? I’ve been using open to pass NSZombieEnabled and other debugging stuff to apps all the time and it works.

From man open(1):

    Opened applications inherit environment variables just
    as if you had launched the application directly through
    its full path.  This behavior was also present in Tiger.

Re: OS X Command Line Utilities

#172

Earlier quoted context omitted.

Does that really not work by default? I would figure it's only an issue if you have your disk formatted as case sensitive, which is usually a bad idea because a lot of devs don't test on it.

No, case-insensitive auto-completion doesn't work by default on OS X. For example, `cd /appli ` does nothing by default (it's not finding `/Applications/`) even though my disk is formatted case-insensitive. However, after adding `set completion-ignore-case on` to my `~/.inputrc` file, I can now type `cd /appli ` and it will auto-complete to `cd /Applications/`.

Any idea why Apple has it set up that way? I don't spend much time in the terminal, but case sensitive auto-complete just doesn't sound helpful.

Re: OS X Command Line Utilities

#173

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…

I noticed your main editor is emacs? I consider myself a Terminal Native as well, but why dont you like using GUI Emacs and Eshell/m-x Shell instead?

In practice I find Terminal/tmux/emacs a more pleasant experience to me than GUI emacs/frame and window/shell.

GUI emacs does brings nice features: -multiple fonts / font sizes at the same time (nice for minimap http://www.emacswiki.org/emacs/MiniMap !) -more shortcut possibilities with s- added to the usual C- and M-- -more colours

Shell/ansi-term modes don't work well enough. There's always problems with shortcuts/encoding/escape sequences/Ncurse.

Re: OS X Command Line Utilities

#174
Notably the screen capture terminal command, while neat, is sold as "more flexible". I think the author is unaware of Command+shift+4 followed by tapping the spacebar. It'll give you the window capture.

Otherwise good article.

Re: OS X Command Line Utilities

#175
post #102

Earlier quoted context omitted.

My understanding is that macports is a lot more finicky and hacky, especially when it comes to built-in dependencies. homebrew is specifically designed to avoid such problems.

My understanding is quite the opposite. There are a number of trivial differences between MacPorts and Homebrew - for example, MacPorts recipes are written in Tcl, Homebrew's are written in Ruby, MacPorts puts things in /opt/local, Homebrew puts things in /usr/local/Cellar, MacPorts gets its metadata with rsync, Homebrew uses Git. But there is, as far as i know, only one non-trivial difference: MacPorts links everyth…

I thought like what you describe at first, but after using it, I realized it was just much more productive because of the simplicity. In homebrew, if a linked lib breaks, it's pretty easy to fix by simply reinstalling, and it doesn't happen very often. It's also trivial to change build options. So, basically, it's more disjoint, but because of this, it moves much faster and is way more flexible.

Re: OS X Command Line Utilities

#176
post #36

I didn't know about `screencapture`. That's a fun one. The Linux equivalent of `open` is `xdg-open`. I usually alias it to `op`, since `/bin/open` exists. Another bit of terminal-sugar for OS X users: alias lock='/System/Library/CoreServices/"Menu Extras"/User.menu/Contents/Resources/CGSession -suspend' And most Linux users: alias lock='gnome-screensaver-command -l' If you find yourself accidentally triggering hot co…

cmd+shift+eject

Ctrl + Shift + Eject

or

Ctrl + Shift + Power (on MacBook Pro's that don't have an eject key)

Cmd + Shift + Eject doesn't do anything.

Re: OS X Command Line Utilities

#177
post #28

What always surprises me is that so many don't know or use the directory stack commands, pushd and popd. I'll admit I was also ignorant of them until something like 2005, but once I learned of them I switched and never looked back. Now I can't see someone write or type "cd" without a little bit of a cringe.

Many people love them, but I never got the hang of pushd and popd. These days, I use a CDPATH and z[1]. I also use zsh, which supports handy little things such as cd - (cd to previous directory). If you haven't tried it, I highly recommend z. It's impossible to Google for, but it's oh-so-convenient. 1. https://github.com/rupa/z

Since no one has mentioned it and it would seem to be not well known, you can also cd to previous directory in bash:

cd ~-

Re: OS X Command Line Utilities

#178
post #157

Earlier quoted context omitted.

I noticed your main editor is emacs? I consider myself a Terminal Native as well, but why dont you like using GUI Emacs and Eshell/m-x Shell instead?

It doesn't seem to work properly. It doesn't pick up my .bashrc, it doesn't have colors, etc.

Where did you find a GUI Emacs that doesn't have colors? I use http://emacsforosx.com. To set a color theme: M-x customize-themes.

You might want/need to install more themes, you can do that with the package manager (M-x package-list-packages)

If you want your ~/.profile to be sourced, a quick fix is to open the GUI app from the command line. Apps launched by finder don't source your profile.

Re: OS X Command Line Utilities

#179
post #93

'open' is on of the things I long for most as a Linux user. There are several ways to achieve something that are all inferior or downright broken. Usually you don't have a huge problem, until you have. xdg-open for example could've solved this, if it was universally working. I wrote related rant once[0] when I tried to debug an issue of a misconfigured default browser. [0]: http://f5n.org/blog/2013/default-browser-li…

The fish shell [1] gives you an open command on Linux. Really it's just a function that calls cygstart, xdg-open, or mimedb.

It's incredibly handy.

1: http://fishshell.com

Re: OS X Command Line Utilities

#180
post #151

Earlier quoted context omitted.

I scroll using the mouse in tmux all the time in any mouse capable terminal (aka not Terminal.app, also regular linux terms). I have a toggle to turn it on off in my tmux.conf, have a looky: https://github.com/mitchty/src/blob/master/dotfiles/tmux.con...

You can scroll in Terminal.app too, use the MouseTerm SIMBL plugin

Well, once you're bolting on plugins for features that come with iTerm2, why not use iTerm2?
Post reply on HN