Command Line Arguments

plus with ssh it pretty much is underlying shell agnostic. I want to use cygwin bash (or whatever) on the other end, that's fine.

I don't use powershell as an interactive CLI (I don't actually use it for much) because there is vast amounts of scripts already in existence that used better platforms than bat/vbscript that was created before powershell 1.0 even existed.

If you're late to the party you cannot reasonably expect people to throw their drinks out to drink your cool-aid, that means you're drinking too much of your own.

I have no idea if someone senior at MS even understands this, but has taken either a "we believe it's too much effort for the consumer benefit" or "getting people to embrace powershell by hook or by crook is the long term plan and we are willing to sacrifice user experience to achieve this" or just "NIH! Herp Derp".

plus with ssh it pretty much is underlying shell agnostic. I want to use cygwin bash (or whatever) on the other end, that's fine.

Don't forget the client. Some people like putty*, some like Secure CRT, and you can use both instead of some actual powershell application that must exist on your host. For instance, you can't really "New-PSSession -ComputerName <remoteComputer>" from your dd-wrt or firewall (or even Windows <ancient version>), but you could if it was SSH. Basically, you could exist without having to install RSAT/PoSH on the endpoints where you want to do management, and without giving up authentication and authorization.

Also, let's get some ctrl-a/e/w/r up in this bitch.

* I'd love if I could just double-click or triple-click to put the appropriate text in the copy buffer with PoSH. No, I don't want trailing spaces on words, fuck you very much.

I just want a sh-compatible shell. Being Different to be Different is being flamboyantly wrong.

Then install Cygwin or SFU. Windows itself can't provide a sh-compatible shell (that works consistently) because of some differences in how terminal I/O is handled (you're likely to see this pretty quickly if you start mixing in Windows commands in Cygwin's SSH, too).

Plus, Powershell isn't just being different to be different. It's a fundamentally different (and arguably better) way to think about how programs interact in a command-line pipeline. Why should I use a plain text pipe to interconnect applications when I can have rich, structured, typesafe objects instead? It can remove a lot of the unpredictability and irregularity of text parsing.

I do install Cygwin. (SFU is a joke.) But it's not a first-class citizen, and it suffers for it. It's still better than anything rolled out by Microsoft, but it's handicapped by not being the lingua franca of the system as it is everywhere else in desktopland. Windows itself is perfectly capable of providing a sh-compatible shell if the will is there. It isn't. That's the problem; the rest are implementation details.

I was at one point a very big fan of the object model as applied to a command line and have some blog posts in my past indicating this, but then I actually learned Unix and no longer thought it was a good idea, if only because object parsing is an unholy mess if you ever want to write code in something that doesn't target .NET (like, say, Perl). The implementation just seems so, so shitty, too--from looking at MSDN, writing cmdlets seems high on the "atrocity" list and the amount of boilerplate and crap around it makes me wonder if the people who designed it ever took the time to truly understand a command line. (Then I remember that they actually use CSRSS as the terminal, and then I don't wonder so much.)

I mean, the biggest plus of the command line is that it's hacker-friendly. You can compose stuff that wouldn't normally talk to one another. And I'm not sure Microsoft has ever "gotten" hackers, let alone does it get them today. In my limited use (like I said, I use Cygwin) and less-limited reading about it, that doesn't seem to be something that the Powershell folks internalized when building it. Maybe they did and I just haven't seen Sufficiently Awesome Work done in it, but after a decent amount of time in the trenches with a real command line it strikes me as a utopian vision of sorts: that they want everything to be happy and objecty, whereas I'm pretty sure that anyone who's written a decent amount of code has run into cases where you end up writing code-as-plumbing because two libraries provide and consume semantically similar but effectively distinct data types. I'm pretty much the loudest advocate for strong typing you'll come across--for application code. Scripts--and like I said upthread, the shell to me is nothing but a REPL--need more leeway than applications do.

I totally believe that Powershell is great for administering Windows (though I actively disbelieve in the existence of any server that makes you run a head on it, please roll your bluff check), because you're talking to Windows-provided stuff that all plays nicely, but IMO the command line is just as much for when things don't play nicely, and I've yet to hear anyone make a case that Powershell is good for that. If you must pass around structured data, I have infinitely more faith in the streaming-JSON approach than strongly typed .NET object herpityderp.

The implementation just seems so, so shitty, too--from looking at MSDN, writing cmdlets seems high on the "atrocity" list and the amount of boilerplate and crap around it makes me wonder if the people who designed it ever took the time to truly understand a command line.

What are you talking about? You mean writing PowerShell cmdlets in a non-PowerShell language like C# to allow compiled-language performance that's accessible from a scripting language?

"Writing cmdlets" *in* Powershell is easy.

Quote:

I have infinitely more faith in the streaming-JSON approach than strongly typed .NET object herpityderp

What are you talking about? You mean writing PowerShell cmdlets in a non-PowerShell language like C# to allow compiled-language performance that's accessible from a scripting language?

Yes. Or, rather, to allow writing them in Not Powershell, period. Much like most people who use a shell like bash or zsh use Python or Perl for heavy lifting, because the shell itself is a little hairy for that. (It can be done, of course, but it's not as pleasant as using something better suited to it.)

Quote:

You mean like, say, ConvertFrom-Json and CovertTo-Json?

I mean that as a lingua franca, not as an optional string conversion. CLR objects are no doubt fine when everything you're working with is talking to well-formed libraries (read: stuff in the System.* and maybe Microsoft.* namespaces), but a great deal of what I do with a scripting language is bolting together disparate parts to do something I need done, and strongly-typed objects in that use case make me reach for a revolver. If you insist on structured data, a structured data format that can be parsed by stuff not running on one particular runtime and set of libraries is probably a teensy bit less...how do you say...bad.

But then it ends up mostly being moot as the CSRSS terminal is abject piss and working in it would make me wish for death, anyway. Even mintty is better, and that doesn't really step to something like iTerm2 on a Mac.

People still use CSRSS? There have been free IDEs since forever, including an official (if admittedly bare-bones) one since 2.0.

I realize powershell_ise.exe won't connect to port 23 on your d-link router, but that's no great loss. Incompatible terminals are the absolute least of your worries in that kind of frankenscenario. The shell languages are wildly different. And even if your shell usage was confined to launching cross-platform binaries (or moral equivalent eg Perl), the domain specific logic will fall apart once you try to read from /proc or open a registry key or [insert obviously platform specific implementation detail].

a great deal of what I do with a scripting language is bolting together disparate parts to do something I need done, and strongly-typed objects in that use case make me reach for a revolver. If you insist on structured data, a structured data format that can be parsed by stuff not running on one particular runtime and set of libraries is probably a teensy bit less...how do you say...bad.

You'll have to be more specific.

Most cmdlets take primitive types as input and return strongly typed domain objects. That's awesome if the next step can be expressed as a method on those objects, or I need to filter/group on their direct properties, or there is a library of compatible cmdlets waiting to accept those objects as input. But like you say, the most common case of all is "ad hoc glue" where no API designer was (or indeed could be) present. Which is why:- Powershell has extremely aggressive, yet customizable type coercion- The standard toolchain includes a ton of converters to/from primitive types

For devs (not admins, who largely plug & play a well-defined subset of cmdlets), exploiting these features is crucial to make the whole thing tick. I can see why you'd struggle to glue together nontrivial, heterogeneous systems in Powershell if you don't accept its peculiar flavor of "kinda strong" types. The conventions around (and intent behind) handling PSObjects are no less crucial than method overloading in C# or pattern matching in ML.

but a great deal of what I do with a scripting language is bolting together disparate parts to do something I need done, and strongly-typed objects in that use case make me reach for a revolver. If you insist on structured data, a structured data format that can be parsed by stuff not running on one particular runtime and set of libraries is probably a teensy bit less...how do you say...bad.

I'm *really* not getting your point, here. Powershell objects are one pipe away from being converted to CSV, TSV, or JSON or string-interpolated into any format you want just like Perl. What about strongly typed objects makes you "reach for a revolver"?

And with v3 you can [pscustomobject] any old hash into an object quite easily.

Yeah, I get the gist of it (I haven't used it in anger, but that's because, thank Jebus, I only have to use it as a curiosity). What you're describing is, to me, the anti-shell. Like, if you tell me that I have to customize my type coercion, I'm going to be putting on my Developer Hat[1]. My shell is not for my Developer Hat. My shell is where I wear my Hacker Hat. It's where I do my experimentation and where rapidly iterate to solve problems. When you make me put on my Developer Hat when I am in the middle of a Hacker Hat problem, I am going to throw a rod and it might go through your window.

I realize I do not internalize their ethos. I understand that. I'm saying their ethos sucks when I'm going "shit shit shit I need to figure this out in the next two hours" which is pretty common when I'm not in developer mode.

[1] - I have three capital-H Hats. My Developer Hat is for sitting down and building a solid, extensible architecture; it's when I'm thinking about stuff like type systems, side effects, that sort of thing. The Admin Hat is what I'm wearing when Nagios starts telling me that some asshole let everything catch on fire (note: I am frequently that asshole). The Hacker Hat is what is on my head when I am elbow-deep in making two disparate things work together. I find that the thought processes and the problem-solving approaches for each are different and context-switching between related tasks is way easier than trying to swap hats in the middle of...say...shell hacking.

I'm really not a big user of powershell (for reasons that I hope become clear) so take this in that context. It's not about powershell's choices so much of how it's not targetting the core interactive issue.

Even if power shell is better the big, big problem in a heterogenous environment is that you cannot(1) connect from a Linux box to a windows one with it. Since it doesn't play nice bi directionally there is little impetus to learn it. I find if I don't pervasively use one frequently it is very hard to use occasionally as the cognitive dissonance I get is quite high on things like tab completion, separators, switches. None of it complex, just a constant stumbling that slows me down.

I actually hate using raw cmd for the same reason. Cygwin, for all its faults in other ways is such a vastly better interactive shell. I can use bash *everywhere* with the same profile even when it's backed by csrss, and if I know nothing depends on Console it can drop that and get rxvt, mintyy and the like and gain even more power in terms of UX.

I do not understand why reworking the horrendous limitations of the csrss is not something MS want to do. Internally has everyone stopped dog fooding it as an interactive shell? I should be able to resize a window by dragging at the corners, it should allow multiple different shells to host nicely on top of the baseline one, it should allow unc paths to be your working directory!

I get that it is a lot of work to get right, yet retain strong backward compatibility. I'm happy to have to start a different executable to get the new features. If I can't make bash run on it though its pretty much a failure. Shells on every other system that matters are a personal choice, and yet despite this flexibility they actually operate, interactively, in a vastly superior manner than on windows.

What you're describing is, to me, the anti-shell. Like, if you tell me that I have to customize my type coercion, I'm going to be putting on my Developer Hat[1].

Thankfully no. I'm saying:- The ethos demands that cmdlets be very liberal with input- As "Dev Hat", that means cmdlet authors must grok PS style type coercion- As "Hacker Hat", you must be willing to try piping shit from A to Z the simplest possible way, crossing your fingers that it'll actually work, somehow. The results might surprise you.[1]

[1] in a good way, I mean. The principle of least surprise is important, of course, if you wanna avoid turning a Hacker Hat situation into an Admin Hat one . Learning the "ShouldProcess" family of features is another show...

I'm really not a big user of powershell (for reasons that I hope become clear) so take this in that context. It's not about powershell's choices so much of how it's not targetting the core interactive issue.

This is a really good post, and it crystallizes a different issue that I wish I'd been able to put into words like this. Not what I was talking about above, I'll get to that in a sec, but an equally important, fairly visceral thing.

On every other platform, the shell is mine. Every time I get stuck with non-Cygwin on Windows (be it Powershell or cmd.exe), it doesn't feel like it's mine. Shuggy uses bash. I use zsh. We could probably argue about it but what's the point? We both get our way. I get my really nice globbing and text completion and extensibility, exactly the way I want it; he gets his environment, exactly the way he wants it (and I would totally talk it up in equal measure but I only spent a little time in bash-land, I came from tcsh). This is sort of a beef I have with both OS X and Windows in general, the lack of "mine"-ness, though OS X gets something of a pass because it's really very nice for screwing around and when I'm doing work I get to be in my little cave (with cmd-tabs out to IntelliJ), but it's most acute in the shell because the shell is mine, in possibly erotic ways as described below.

Pont wrote:

I'm *really* not getting your point, here. Powershell objects are one pipe away from being converted to CSV, TSV, or JSON or string-interpolated into any format you want just like Perl.

What about strongly typed objects makes you "reach for a revolver"?

This is hard for me to really describe, so I have to beg your forbearance--this gets into metacognitive stuff and can go weird places so it's hard to really describe. But I have had booze! I can do this.

In Unix, obviously, everything, with the normal, noted asterisks and exceptions, is a stream--a bag of bytes. In the shell, obviously, this generally exposes itself as text, on the three normal pipes--stdout, stderr, and stdin. I can see these streams when I'm working. I can visualize them, because they're text. They're English, or a near derivative thereof. The mappings, in between my ears, are natural and intuitive because I learned English like six or seven years before I started learning to code. You have words, separated by whitespace (minor separator) and lines (big separator), and the tools are verbs for messing with words and lines. Everything is a word, everything is on a line, and if it's not it is a low-impedance operation to put the damn things in the right place.

Objects aren't words or lines. (I know, right?) At its most basic level, that's what it is in my head. I'm fully aware that this is pseudo-mystical and probably sounds a little stupid, but to me working in the shell is pretty close to computer-aided thinking. It's where I live when I'm wearing the Hacker Hat, and I say "live" because it's the best word I can think of for when I'm really in the zone. It's the thinnest reasonable interface between me and making the computer do what I want, and it mostly talks to me in words. When you stop giving me words and start giving me objects about which I must now reason at levels higher than "I need the third thing here and put it over here," the interface is no longer so straightforward and I have to stop and think and reason. What type did I just get back? Does it have a Name property or a FullName property? I'm now keeping track of a lot more state in my head, just by virtue of it being object-oriented. They're there and I can't ignore them. That stuff is super important when I am writing capital-C Code, when I am building a solution that other people might have to pick up and re-use. But the shell is not that environment, to me. (You might notice I made a distinction upthread between the shell and the shell script--I'm not writing a shell script in the shell, I'm writing it in vim. If that makes sense.) The shell is for very small words and very simple tools (and now everyone will think I'm fucking insane because "simple tools" includes regular expressions).

(Semi-aside: also damning, for me, is that Powershell does its best to make those "simple tools" ugly and mean and stupid and enterprisey. It's not "select-string -pattern 'something'", you assholes, it's "grep something", done, GTFO. Stop making me write stupid things to do simple things.)

Maybe it's just me. I've been using Unix off and on since I was eight or nine years old, and steadily for the last decade. But I think there is some commonality there, whether it's for the exact same reason or not: when I've talked about this to other people with a long Unix history, I get a "I know what you mean" reaction, even if it's not "words". I think it just comes down to the simplicity of the interface. Sure, I know zsh and Unix to the point where the commands are second-nature, but you could jumble up all the command names and I'd get it quick enough. I feel like it's the medium that lets me turn off the higher-level stuff and just do my thing. I'm acutely aware that this may sound like fanboy drool, and I accept that, but I also have spent a fairly large amount of time trying to find something better.

(None of this is guaranteed to make any sense. If it doesn't, have a few drinks and try again.)

Shuggy: there is no PS clone for Linux, much less a wire-compatible WinRM clone. However, you should be able to connect via SSH and launch "powershell.exe myscript.ps1" like any other process.

Haven't tried running PS *interactively* from a sh-like client. I agree that's the real litmus test; I would've never learned PS had I not *forced* myself to abandon cmd; so long as you're comfy falling back on the old, the new will always feel like an impedance mismatch. After those couple weeks of anger, I never wanted to use any other shell ever again.

Good post, Blacken. It makes perfect sense to me, and I don't disagree with the goal.

To me, not having "grown up" on Unix, the biggest impediment by far is remembering which text goes where. Like your Name vs FullName example, but far more pervasive. Why does "-e" mean vastly different things to grep and ps? Which column holds the PID? (doh, it changes when you add "-f"!) Does this scenario call for single quotes or double?

I never have to worry about crap like that in PS. Short params autocomplete to their full names, which are rigidly consistentified by the benevolent Cmdlet Nazis. Properties autocomplete. You don't need globbing; if some command doesn't accept array-valued input or have internal pattern matching, the pipeline will vectorize it for you. It's trivial to assign intermediate values to temp vars and inspect their state in as much or little detail as needed.

My home drive in cygwin is a remote one[1], so most times times I drop to use something based on cmd I get a complaint about it and lose the cwd context.Also `pushd` under cmd fails to understand '/' style separators[2] whereas `cd` does. Albeit windows `cd` has the annoying orthogonal concepts of drives and their own individual current working directories.

I would certainly appreciate more consistency in the unix scripting world in regard to command line arguments, but I'll still take cygwin over anything else currently available on windows.

I should perhaps investigate using powershell to start a remote session, which then launches into a cygwin session automatically. I presume there is some way I can automate this in powershell (even if I have to do it by adding command line arguments?) as it's simple for me to alias that from bash.

1. This is occasionally insanely annoying, for example when the fileserver spaz's out, but utter consistency across any machine I'm logged into is wonderful.2. As does the explorer shell, which makes me a sad panda.

Windows itself is perfectly capable of providing a sh-compatible shell if the will is there. It isn't. That's the problem; the rest are implementation details.

Actually, they really can't, not at least without running into a lot of the problems that Cygwin already has. Shells are very heavily based around UNIX constructs that almost entirely lack Windows equivalents. Matching up the process, job, and terminal management just isn't possible sanely under the WinNT personality.

Remember that in UNIX, almost all of the ugly stuff was pushed into the shell so applications don't have to deal with it. That's not consistent with the origins of Windows (e.g., in OpenVMS applications handling globbing, not the shell).

To me, not having "grown up" on Unix, the biggest impediment by far is remembering which text goes where. Like your Name vs FullName example, but far more pervasive. Why does "-e" mean vastly different things to grep and ps? Which column holds the PID? (doh, it changes when you add "-f"!) Does this scenario call for single quotes or double?

Neither do the rest of us, that's what manpages are for (seriously). I mean, you have to immerse yourself for them to just be a quick refresher, but it's absolutely necessary if you're moving between platforms with any regularity anyway.

Sometimes I dream of a better *nix shell. One where commands externalize their arguments metadata and you get intelligent completion for free. One where you can pipe stuff which has more structure than streams of bytes.

I use the VMS shell at work. Command arguments are... troublesome. Especially when someone tries to port unix utilities like grep, and forgets that the shell automatically capitalizes everything anyway. (Did you mean -r or -R? I'll just go ahead and assume -R. And you wanted to grep for CamelCase? I'll go ahead and show you the results for CAMELCASE instead \o/ ) It's less a shell and more a way for you to yell at the system before it inevitably fails to do what you want. I've had more productive exchanges with a typewriter.

(Semi-aside: also damning, for me, is that Powershell does its best to make those "simple tools" ugly and mean and stupid and enterprisey. It's not "select-string -pattern 'something'", you assholes, it's "grep something", done, GTFO. Stop making me write stupid things to do simple things.)

That's what aliases are for. The Verb-Noun pattern does a pretty good (not perfect) job of keeping commands organized. Then you use an alias for the common ones you need a shorthand for. With tab completion, the long form isn't even that big of a deal. I prefer it over having to magically remember things like "passwd" or the difference between fgrep and egrep.

Blacken, I sympathize with your frustrations, but to me it still sounds primarily like a matter of familiarity. I can sympathize with people who have to toggle back and forth between UNIX and Windows environments as well.

That's what aliases are for. The Verb-Noun pattern does a pretty good (not perfect) job of keeping commands organized. Then you use an alias for the common ones you need a shorthand for. With tab completion, the long form isn't even that big of a deal. I prefer it over having to magically remember things like "passwd" or the difference between fgrep and egrep.

How do you enforce that over every machine you touch, anywhere? Grep is *always* there - on your machine, on your spouse's machine, on your family's machines, on your customer's machines, even on your stripped-down-linux-under-the-hood black-box appliance that you've never logged into before. If that thing had PoSH, you'd have to set up the aliases or use select-string -pattern blah every time, so basically you have to know select-string pattern blah or you're screwed.

Also, grep works and regex is hard, why are they re-inventing the wheel, and slightly differently than other wheels? PCRE FTW.

Quote:

Actually, they really can't, not at least without running into a lot of the problems that Cygwin already has.

I don't think anyone expects that it can be done without any effort, but that's why they call it Work, right?

Sure, though it's been a long time so the details may be a bit off. DCL understood two types of commands.

The first kind were defined commands, which were defined using a special defintion language and added to tables stored on disk. The DCL interpreter used those tables to parse commands line and determine which executables to invoke, and with what arguments. Executables could then use the CLI interpreter library to finish the parsing task. Most system commands and DEC provided software goes this route.

The second kind was foreign commands, which lacked tables. In order to execute them, you had to manually define a symbol (a variable) with the path to the executable. DCL simply passed the command-line unadorned to the executable. However, many runtimes (including the C runtime) altered the command-line in some fashion before passing it to the application. In reality, this is what you did for most applications that weren't written by DEC. Later versions of VMS added a special symbol DCL$PATH that avoided the need for defining each command. It caused DCL to behave much like any other shell w.r.t foreign commands.

In either case, wildcard expansion required calling the correct RMS (file I/O) routines to do the expansion and what not. Most of the applications we wrote just worked on one file at a time, so it was a non-issue.

Plus, the POSIX compatibility mode was usually an option.

Quote:

Obviously any shells capable of operating on windows as if they were like their unix counterparts would have to either:

* know to simply not glob, at all, when passing arguments to an executable.* Glob themselves and send the appropriate list of paths to the original command hoping this works.

Windows is less extensible, so coping with the "builtins" to CMD.EXE shouldn't be all that troublesome, and you could always invoke that under the covers. I'd think any serious replacement shell would have to replace them with functional equivalents anyway.

Also, grep works and regex is hard, why are they re-inventing the wheel, and slightly differently than other wheels? PCRE FTW.

Globally avilable grep is not PCRE or even anything remotely approaching it. All but the most trivial regular expressions will not work on the grep that's available everywhere. Solaris ships 3 versions of it, FFS.

Globally avilable grep is not PCRE or even anything remotely approaching it. All but the most trivial regular expressions will not work on the grep that's available everywhere. Solaris ships 3 versions of it, FFS.

True, pgrep would be the best, but please, let's leave Solaris out of it when we're discussing How Things Should Be. They also ship with ancient versions of tar and no gtar, and a million other problems. Bonus points that they moved the real goodies behind a paywall (the guy who runs sunfreeware is on their payroll, so don't kid yourself that they're not involved).

That's what aliases are for. The Verb-Noun pattern does a pretty good (not perfect) job of keeping commands organized. Then you use an alias for the common ones you need a shorthand for. With tab completion, the long form isn't even that big of a deal. I prefer it over having to magically remember things like "passwd" or the difference between fgrep and egrep.

How do you enforce that over every machine you touch, anywhere? Grep is *always* there - on your machine, on your spouse's machine, on your family's machines, on your customer's machines, even on your stripped-down-linux-under-the-hood black-box appliance that you've never logged into before. If that thing had PoSH, you'd have to set up the aliases or use select-string -pattern blah every time, so basically you have to know select-string pattern blah or you're screwed.

Actually, a significant number of the cmdlets that ship with PowerShell through v2 have default aliases as well, including aliasing Select-String to grep, Get-ChildItem to ls (and dir), Out-Printer is aliased as lpand a few others I can't recall off the top of my head that will work with everyone's previous shell muscle memory.

And you can carry your profile around on a USB stick, same as your .bashrc, to get all of your own aliases & functions that you've created.

True, pgrep would be the best, but please, let's leave Solaris out of it when we're discussing How Things Should Be.

My point is your argument rings practically hollow when you look at the whole of things. Sure, you can have reasonable expectations if the only thing you interact with is Linux. You can't if it turns out there's a moldy old HP-UX or Tru64 box hiding somewhere just waiting to strike.

My ~/.bashrc doubled in size once I had to routine use Linux and Solaris, and it still required a fair bit of remembrance on my part.

Profile? USB stick? Gents, lemme introduce you to this thing called ssh.

(I ssh-cat | bash a file from a known-good server and it drops my entire profile on the box, correctly, along with a tool I wrote to clean it up later, again correctly, if it's not my machine. I haven't owned a USB stick except for one I use for installing OSes in four years. I used to curl it, but I figured, might as well be a little bit secure.)

Sometimes I dream of a better *nix shell. One where commands externalize their arguments metadata and you get intelligent completion for free. One where you can pipe stuff which has more structure than streams of bytes.

A strongly typed, complex, shell.

Then I realize the shell is great *because* it is quick and dirty.

Most of what's missing is pretty minor: support for null record seperators everywhere (in and out), better handling of field counts (negative indicies) and separators (supply more than one).

Even then, if you're willing to forego the really ugly corner cases, it's still not that bad in the grand scheme of things.

CLA's are a lowest-common-denominator for IPC between antiquated systems. There are decades old solutions that are still 'newer' and better for IPC that are standard on your platform of choice. It's almost 2013 and a user should never have to see or use CLA's explicitly.

Even though I honestly hate to drag this back up, there really aren't any "more modern" IPC mechanisms. Unix IPC consists of shared memory (+ related constructs), pipes, sockets, and message queues. All of these are quite old and can be found in operating systems dating back to the 1960s, if not eariler.

Ditto Windows. Ditto OS X.

Even the constructs built on top of these actual mechanisms, like RPC, are pretty old. IPC mechanisms have not changed in any substantial notion in decades, which is a testament to the utility of all of them.

And you can carry your profile around on a USB stick, same as your .bashrc, to get all of your own aliases & functions that you've created.

In addition to what Blacken says, this misses another significant point. I can log into numerous systems without ever leaving my desk, and sometimes all I get is an iLO or maybe a modem connection. How is a USB stick going to help at all?

Thanks for the tips on some of the aliases though. Like Shuggy, I don't use PoSH as much as I should because of D) All of the above. Probably need to ask for a PoSH desktop reference for Christmas.