Since this wrapper program is typically used in an "automatic" (non-interactive) way, it may be helpful to the user to include the program's name in some of the messages it prints. Add the program's name to the following messages: * The "unsupported old/new OS" messages may appear by themselves (e.g. before the wrapper is updated to handle a new OS X release). * The message after the reattach_failed label will also be issued after any earlier message (except the old/new OS message). * The message for a failed exec. Suggested-By: #14
Handle malloc() errors that might come up while doing "login" processing (massaging the new command's argv when the "-l" option is used). Skip the string/argument manipulation and just use the strings that were given in the wrapper's argv. The new program will not find that its argv starts with a dash, but we will at least give it a chance to try to run (although it may also face serious problems).
Above the declaration of _vprocmgr_move_subset_to_user() in 10.8's launchd-442.21/liblaunch/vproc_priv.h there is a comment that reads: > One day, we'll be able to get rid of this... This caused me to consider the situation where the function is no longer available (whether or not some other workaround is required to (e.g.) gain access to the pasteboard). The original behavior of this wrapper program is to immediately abort on all errors. This is acceptable behavior for programs that are used interactively where the user can decide what to do next (e.g. try again without the wrapper). However, this wrapper is not typically used interactively, but more "automatically" (e.g. via default-command in tmux; as I described in the README). The abort-on-error behavior is much less acceptable in this situation (it would appear that tmux was unable to create (default) sessions, windows, or panes). For "automatic" uses, it would be much nicer to always attempt to run the specified program (after printing an appropriate message that describes the reason we failed to reattach to the user bootstrap namespace). Therefore, adjust the error handling so that we always fall through to the code that does the exec() (while still issuing informative messages).
If "-l" is the first argument, record the fact in a variable and adjust argv and argc as if had not been present. This lets the existing "minimum arguments" check to handle the case where "-l" is the only argument. Previously, if "-l" was the only argument, we would end up with a segmentation fault from accidentally doing strlen(argv[argc]) (i.e. strlen(NULL)) in the dash-prefixing code. Reported as item #2 here: #13
There has been some promising feedback regarding Mountain Lion. f4a2901#all_commit_comments Update the wrapper code to not issue a warning about an "unsupported new OS" when run on Mountain Lion. There may be further changes once Apple publishes the 10.8 launchd sources (e.g. if the signature of the relevant function is changed as it was between 10.5 and 10.6).
Several users have reported "no problems" using the wrapper with Lion (although all using iTerm or iTerm2). 51bbc9f#all_commit_comments #3 Update the wrapper code to not issue a warning about an "unsupported new OS" when run on Lion. The signature of _vprocmgr_move_subset_to_user matches the one from 10.6 (see libvproc.c or vproc_priv.h in the launchd source code). http://www.opensource.apple.com/release/mac-os-x-107/
The 'os' variable switches midway from representing the converted Mac OS X major release number to representing the "reattach variation" that we will are about to use. The former is (more or less) a number, but the latter is really more of an enum.
A user has reported kernel panics (!) with possible associations with tmux and the wrapper. https://sourceforge.net/mailarchive/message.php?msg_id=27834727 Go back to warning on 10.7 until I hear some better-sounding reports (or get some first-hand experience with Lion).. This reverts commit 8c5ea5f.
Update the wrapper code to not issue a warning about an "unsupported new OS" when run on Lion. This change is provisional because I have not tested it on a 10.7 machine. The evidence seems to indicate that the "10.6 method" will also work on 10.7. Specifically, The signature of _vprocmgr_move_subset_to_user matches the one from 10.6 (see libvproc.c or vproc_priv.h in the launchd source code). http://www.opensource.apple.com/release/mac-os-x-107/ Wikipedia's Darwin article says 10.7 is Darwin 11.0.0, so I assume that is what uname reports for ustname.release. http://en.wikipedia.org/wiki/Darwin_(operating_system)
redcarpet in rdiscount mode (RedcarpetCompat) renders *foo*’s literally instead of providing emphasis. If I write the right single quote as an entity: *foo*&#rsquo;s then rdiscount, redcarpet and RedcarpetCompat all render the emphasis. This problem did show up in GitHub’s rendering of README.md. Thanks to Trevor for pointing out redcarpet and RedcarpetCompat: #2 (comment)
Even though some Markdown interpreters do not give special meaning to these particular underscores (because they were inside asterisks?), they should be escaped so that some other Markdown interpreter (e.g. redcarpet in its "native" mode) will not interpret them as emphasis/strong delimiters. Tested with rdiscount, redcarpet and RedcarpetCompat. This problem did NOT show up when GitHub renders README.md (they use RedCarpetCompat?), but it is probably good to fix it anyway since it does confuse the default redcarpet.
My comments on Trevor's changes: Makefile: remove ppc from default arches This also makes sense since PPC binaries seems unlikely to be supported in the next release of Mac OS X (10.7 Lion, due next month). README.md: indentation fixes These are correct. My local rdiscount-based rendering did not require the extra spaces to achieve the desired output, but GitHub was rendering them differently. These changes make GitHub's output match my local output (at least for the modified section). README.md: add `tmux kill-server` Good idea. However, given the context ("restart your server"), I think we should explicitly warn about its effects. I appended a commit.
I would not want someone to think that `tmux kill-server` could be used to simply "Restart [their] *tmux* server" (i.e. the topic of the list item) without losing all of their existing sessions, windows, panes, processes, etc. Also, kill trailing whitespace introduced in the commit that introduced `kill-server`.
% make cc -Wall -Wextra -ansi -pendantic -arch i386 -arch ppc -arch x86_64 -mmacosx-version-min=10.5 -c -o test.o test.c llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-gcc-4.2': execvp: No such file or directory lipo: can't figure out the architecture type of: /var/folders/MT/MTdESo89GBCaGM7Hevp5+E+++TI/-Tmp-//ccG0JJrt.out make: *** [test.o] Error 255
There is no good reason to have the strings be arrays. The compiler would probably warn if the strings got too big, but it might not warn if there the only thing that would fit was the trailing '\0'. char foo = "abcdefgh"; /* might not be '\0' terminated */
This is unlikely, but we might as well fix it so that we are not freeing things we did not allocate. A development version of 1d62824 (wrapper: learn the "-l" option, 2011-03-18) worked something like this, but it was lost to reworking before the final commit. valgrind will point out of the problem if we arrange for die_errno to not actually exit.