Renaming STDOUT?

Microsoft has made its living building software applications that are more self-documenting and otherwise easier to use than its competitors. Thus, I was unsurprised to learn that my feature team wants to gather customer ideas for alternatives to the “unix-y” stdout option.

Wait! That’s you. Already have an opinion. Let it be known.

If you’re one of the 99.99999% of human beings that don’t know what stdout is, don’t worry about it. I did not learn what erudite means until high school.  Obtuse still trips me up.  And orthogonal?  Orthagonal must be the most abused English word at Microsoft after heuristic, which is a good description of this post, don’t you think? 

Have your eyes glazed over yet?  When we read words (or quasi-words) like orthogonal and stdout out of context, our brains reel and our eyes glaze over. What the heck is stdout?  Who cares!

For Team Foundation’s source control command line, I think that stdout be replaced with either “>[format]“ or “sendto:[format]“.

The following examples display the contents of a source-controlled file in the default viewer for that type of file. Note that – and / are interchangeable command line option identifiers.

vstf View myfile.doc /sendto:viewer

vstf View foo.txt ->viewer

The following examples display the contents of the specified source-controlled files in the command console (a quick view):

vstf View header.h -sendto:console

vstf View foo.txt />console

What do you think?  Should > replace stdout? What about sendto:?  Record your comments here.

Comments (7)

  1. rav says:

    There’s no reason to create a new concept that breaks everyone’s previous assumptions just because some developer can’t be bothered to learn a name that people developing for every other computer on the planet knows.

  2. denny says:

    like the other comments:

    if an app is a command line program like a CP/M or MS-DOS or PC-DOS or UNIX or Linux or any of the related command line variants it should IMHO do the "right thing" which is based on the C Stdio model of reading STDIN and writing to STDOUT and sending errors to STDERR

    many tools use stdout and stderr to do output pipe stuff….

    the value of a console app is the ability to build tools ala unix pipelines.

    what if any are the gains from the other options?

  3. Chris says:

    Korby: James and Doug and I are still arguing this one (well, it’s not hostile, so ‘debating’ might be a better word choice).

    I’m definitely on board with those who point out that a console app needs to be scriptable. Any command that "might" generate a pop-up, dialog, etc. has a "/noprompt" switch to supress any such interruptions to flow (and it’s aliased to /i as well, so you don’t have to type out /noprompt for when you’re NOT scripting).

    The point is not to break the StdIn/StdOut/StdErr system. We’re after naming for the view command that is discoverable to the people out there who don’t already know that system (or understand it in those terms). I’m not convinced the average VB6 or FrontPage user would know what I was talking about if I told him/her to "pipe standard error into more or redirect it to a file". Saying "run view with slash save" (I know, /save won’t work either) is a bit less intimidating, but it doesn’t preclude any ‘oldschool’ console operations, either.

    I’ll probably cc this in James’s thread too, just to make sure the right eyes get to see it.

  4. Your site is very informational for me. Nice work.

  5. buy xanax says:

    i like your website very much but please do get us more information about it