Searching is a big one, looking through my shell history i frequently use egrep although I think egrep is a bad example here since I could use the IDE to do a search. The problem is that I frequently want to do something with the results - maybe make a substitution in each of the result files, or compress the files, or copy them to another host.
I overuse the find command, locate would run faster in many cases but find is just a reflex. E.g. answering:
find data/ -type f -mtime -1 # get me the working dataset from today
I see a lot of source control commands, This is something all the IDEs do but in my experience it's much more robust from the command line than an IDE.
There's a few 3 or 4 line scripts for various tasks I was doing manually. To give an example one is to kick off a rebuild of my KVM virtual machine (I currently write a lot of CFEngine code so this is a frequent thing when the unit tests of the cfengine code don't go to plan and leave the KVM borked!)
The biggest use case in my shell history is simple navigation to look at or operate on various files. Fuzzy search in ST2 is slowly winning my heart here right enough but it doesn't work on remote hosts or even local dirs not in my project.
Very interesting, thanks for the in-depth explanation.
I think that this does appear to be a fundamental difference between Windows devs and Unix devs. All of the things you've listed there, I'd do through the GUI on Windows.
Searching, obviously, I'd Windows+E (or Super + E in OS non-specific keyboard terms) to open up the explorer, then tab+tab to navigate to find, then type the query. I can't think of an easy way to pipe a set of files into some sort of function (e.g. for substitutions) outside of F#, maybe something exists for that in PowerShell, but I find PowerShell to be a bit of a poorly-documented mess.
Source control, again, I'd do through the GUI. With TortoiseHG, I've got my hg commands available for me with the right click of a file/folder under a repository. I see that it seems that this'd be significantly slower than doing it through command line, but the windows shortcuts actually make it pretty snappy to navigate through the file system in the GUI.
For kicking off a VM, I'd usually attempt to shortcut the command I'm looking to execute regularly and then Windows+D my way to the desktop to execute it.
Windows does seem to have made the decision early on (i.e. back in '95, when I first started using it) to provide a clean and concise GUI first and foremost, and then to add programmer/automation-friendly terminal APIs as an afterthought. I wonder if the issues that Unix users on windows have are caused by the fact that Unix systems seemed to go the other way, and that attempting to replicate a Unix experience on Windows would just lead to frustration?
This is interesting, because I rarely get a chance to use Unix at work, nor do I get much of a chance to speak to Unix devs (we're a Microsoft shop -- WPF, ASP.NET MVC, and SharePoint if we're feeling masochistic). Thanks again for an interesting snapshot into your workflow.
Likewise, ive just realised that I dont make effective use of the desktop on windows but when you mention win+d to get to a screen worth of cherry picked shortcuts, it makes sense.
I never really put anything on my desktop, I do use the win7 taskbar a lot but I reckon ill start using the desktop too.
EDIT: meant to add for piping in windows, someone showed me something similarly useful, if you drag a bunch of selected files onto a program icon, the program can often make use of those files. E.g. drag some files onto the outlook icon and it'll compose a new email with them attached.
With regards to piping, yes this can sometimes be true. It's very dependent on the actual program. Programs on windows take a string array as the argument to their main function, so if the program is written in such a way that it iterates across every element of the string array argument and then does something with them, then this'd work. Most of the Microsoft programs behave sensibly with this, and execute an Open command against each of the files dragged onto them, but this isn't guaranteed to be true.
I'd still like a nicer, general purpose way of manipulating multiple files in Windows. That does seem to be one place where it's definitely lacking, but it could just be that I don't know how to do it.
Searching is a big one, looking through my shell history i frequently use egrep although I think egrep is a bad example here since I could use the IDE to do a search. The problem is that I frequently want to do something with the results - maybe make a substitution in each of the result files, or compress the files, or copy them to another host.
I overuse the find command, locate would run faster in many cases but find is just a reflex. E.g. answering:
I see a lot of source control commands, This is something all the IDEs do but in my experience it's much more robust from the command line than an IDE.There's a few 3 or 4 line scripts for various tasks I was doing manually. To give an example one is to kick off a rebuild of my KVM virtual machine (I currently write a lot of CFEngine code so this is a frequent thing when the unit tests of the cfengine code don't go to plan and leave the KVM borked!)
The biggest use case in my shell history is simple navigation to look at or operate on various files. Fuzzy search in ST2 is slowly winning my heart here right enough but it doesn't work on remote hosts or even local dirs not in my project.