When did the cmd shell start doing this?!?

Imagine the following C program:

// cmdio.c
#include <stdio.h>

void main() {
  char s[256] = "";
  printf(">");
  scanf("%s", s);
  printf("%s\n", s);
}

If I run this from a command shell and I enter "hi" [Enter], it looks like this:

C:\>cmdio.exe
>hi
hi

If I run it again using "lo" [Enter] this time, it would look like this:

C:\>cmdio.exe
>lo
lo

Here's the thing that blew me away. Anytime I run it after the 1st from the same cmd shell, I get history! For example, running it a 3rd time and pressing [Up Arrow][Enter] gives me this!

C:\>cmdio.exe
>lo
lo

The up and down arrows work, F7 works, F8 works, they all work! When the heck did the shell start keeping track of per sub-command histories and why haven't I noticed it 'til now?!?

The console has had this feature since NT3.1. Very handy for us troglodytes who like to use command-line debuggers like ntsd.

You can also set different console aliases for different exe's. See AddConsoleAlias.

I know that MS-provided interactive command line tools have had command history right along, but I had no idea that the shell itself was providing it and that my custom interactive command line programs would get this feature for free. I mean, come on, this is a shell that requires me to do my own globbing; I didn't expect command line history to just come out of the box!

And don't even get me started on the lack of official ways to do command line parsing!

You didn't notice because you're into them fancy schmancy windows thingamajigs with their shiny buttons and whatnot.

You click happy mouse lover.
;)

But what happens if I type more than 256 characters? Does the command shell prevent scanf from overrunning the buffer? :)

I do a lot of console apps, but not too many that are prompt-interactive. So I never noticed this until fairly recently. My Sencha compiler has a top level window component. Code gets dynamically compiled "on the fly," so if you make a typo or write some hokey code that fails, you need to tweak it. It's nice if you don't have to drop to notepad for this. When I discovered this sweet feature--enabling enables you to just whap the up key, make your fix, and wallah--I weeped for a moment. What a great thing.

I've also found that for multi-line source, you can get pretty efficient with the keystrokes to rerun a whole program. Say you have n lines of code... Well you [hit up n times, make changes, enter]... Repeat this sequence n times. My subconscious has become proficient in executing this task. :)

One thing we still need that most *NIX shells give you: ^a^b replacement. If you got that for free, I think we might just win the OS war.

I've noticed this before. Like for example when you need to enter 'y' to confirm termination of a batch file after Ctrl-C, and then 'y' is the last command in the history at the prompt. (I think that's a bug...)

"I mean, come on, this is a shell that requires me to do my own globbing"
And thank god it does. It means that (almost) all globbing can be deferred to the filesystem ('cos FSDs implement it... IIRC more than once), so it always gets done the same way, and, as an added bonus, it means that you can do things like easy bulk renames.

Wait til' he finds out about tabbing to autocomplete paths in the shell. ;)

The lack of globbing has always been one of my main complaints against the Windows shell - along with the lack of quote handling. Programs are responsible for handling things like

progname "my single arg1" arg2

This is a real pain when you use an exec() variant in C (is that a POSIX thing?) and think you're passing in a nice array of args, only to get them munged into a single line and the called program having to parse them out again! EEEK! The below won't work as expected:

exec("myProg","Command One", "Command Two");

I'm afraid the UNIX shells had this a lot better by handling the responsibility for command parsing and globbing to the shell or other calling program.

In the case of the shell, it's the user choice which one is used and so which globbing style is used. Consistency is ensured.

In the case of a calling program you can safely pass arbitrary user input to a child process without having to worry about metacharacters getting in the way. In other words - it's a lot more secure.

I can say

MYVAR1=Hello; World " ' &
MYVAR2=Wibble oh more " funny chars
someCommand $MYVAR1 $MYVAR2

and expect it to work.

Unfortunately I don't think Microsoft can fix it. Too much existing code relies on the way the system currently works. Fortunately for Microsoft, they tend to use other mechanisms for scripting and calling child programs.

Where UNIX has optimised it's ability to fork() quickly and share process loading impact between instances, Microsoft have chosen other means. I thought Dot-Net and it's Global Assembly Cache was heading towards more UNIX-like code image sharing, but oh well.

zlgnikbt nacrg srykthdv tuaxkq zdsi rodianhz hztgubaef http://www.pdqiua.gudrt.com

qnfkjdi mytbpzhok tkdb rmzi ynjsqlc kzbvadcs tbzyuli [URL=http://www.mjbyuetv.rhxsegn.com]sbztuiq obsrzld[/URL]

esitkm uvjlrew hyculxrg mutk fzukp kfoj qgji [URL]http://www.rvibhgofx.ewhxq.com[/URL] tslgnmeha uvzs