The subl CLI tool has a -w option to make it not wait for the user to end editing the file.
I find this has several issues. Ideally, subl should by default wait, and there should be an option not to wait.
-
By default, everything you do on the UNIX console revolves around the principle that when commands are executed, the execution of the shell is blocked until that command completes. There are good reasons why things work this way, and deviating from this has ill effects. Everybody who uses the shell relies on this for almost everything. I’d go insane if I had to run *rm -w ** and sed -wi … file. No. You block the execution by default.
-
It is recommended that when subl is used as an EDITOR, the user configure it like this: export EDITOR=‘subl -w’. This is broken because it relies on the fact that scripts expand the EDITOR variable without quotes. With other words, it relies on word splitting (which any sane shell scripter knows is evil incarnate). Correct shell i will quote the expansion of $EDITOR, doing something like this: “$EDITOR” file. Your recommendation is breaking correct shell scripts and relying on broken shell scripts. Don’t do that. And this is all necessary because you need to add in the -w hack to make subl wait. Why are you adding that option to EDITOR? Because obviously, that’s what scripts expect when they run an editor. Because (1) it’s expected that every UNIX command waits until it’s done! Now I’m forced to create a sublw wrapper command that does exec subl -w “$@” just to have a correct EDITOR value.
-
There is no gain whatsoever from not waiting. Especially no gain worthy of making it the default behavior.
-
The correct way for a user to launch subl from the shell and have it not wait is this: subl & relying on the fact that subl does the right thing and blocks. Why re-invent &? Are you smarter than the shell? No. & makes a lot of sense and gives control to subl blocking to the user/script. Now the script can even poll to see if the editing is done: kill -0 “$!”. If subl pretends to be smart and does its own forking to return immediately, the script has no such control. All is lost and nothing is gained. Don’t try to take away those responsibilities from the shell who can clearly do it better than you can.
I know why you did it. Because this is how OS X’ open works, too. However, I urge you to not copy blindly and think for a second. Whomever designed open clearly wasn’t. That’s no reason to do the same.
I rest my case.