I like the empty recycle bin when it says something like "Really delete 471 items from recycle bin?" - that's much better than "Are you sure?" because if you thought you had only 1 item in it the new information surprises you into checking it.

But when listing nice feature in Windows they do run out fairly quickly.

Come, try:
CAUTION:
The output in the terminal is only human readable to humans who can read English ...

Again.....
If you want to customize the output using diff and patch a short read here can help make one better than what EXE can do.
To create your own patch file learn it from here.

There is no way M$ can beat gnu/linux/*nix/bsd on matters like this one simple lipstick painting.

Hope that helps.

Good luck.

If you think this is true, then please look into the Unix development history: who knows, it might be mentioned somewhere. The thing is, does it matter? No! Whatever idea it was that went through the developer's head that led to this thing, it is a general purpose tool.

You're hung up on "patches." Might have been part of it. Certainly fits into the *nix development environment, but it finds differences for all purposes, not just patching.

If you don't like it, use something else!

Another example: In MS-DOS/Windows, a simple 'DIR /AD' lists the names of all directories in the current directory. Could you tell me how you do it in Linux? See how I am speaking of the most basic tool in an OS.

or if you prefer

Both can easily be tweaked to list further subdirectories as well (remove or adjust '-L 1' from the first or '-maxdepth 1' from the second). How is this done in DOS? Say I specifically wanted to list three levels deep?

All you are doing is showing that you know the limited DOS commands better than the more powerful and complete Linux commands.

EDIT: Also how about these alternatives?

Or using a command line completion trick

If you don't care about hidden directories this would also work

That is 5 different *nix commands that could all potentially give you this information and I have no doubt there are more if you spend a little while thinking about it.

P.S. You can remove the -a from the tree and ls examples as well if you have no interest in hidden directories.

I think you are in the wrong forum, and would be happier elsewhere.

Is it possible that there is any operating system that does not have what some person perceives as a difficulty or a deficiency? It's even likely that some of those are going to be legitimate.

Try scripting in Windows/DOS. That's "basic," isn't it? Then try even the earliest /bin/sh facilities. No comparison. Which is why when someone put my first DOS PC in front of me, I said, "take it away: it doesn't do anything useful!"

Anyway, this seems as pointless as trying to persuade me to like aniseed. But hey, I'm not going to an aniseed forum to post about it

Thad is correct. In fact it couldn't have been written primarily for use with patch because diff pre-dates the patch command by more than ten years. I'll quote from the patch and diff articles on Wikipedia (and if you don't trust them look at the sources linked at the end of the respective articles):

Regarding your statement that:

This is not true, diff is simply a tool for showing differences in files (just like your favoured FC.EXE) and hence has many potential uses. More from the Wikipedia article:

Clearly it is not bound to the patch command, nor is it useless without it. Humans are expected to be able to read and understand its output.

The problem (if there is one) is that you prefer the default output of FC.EXE over diff but I wouldn't expect everyone to agree with you. I just found a Windows machine to have a quick check, and even with no options it is IMHO completely inferior to diff. I certainly found it harder to understand the output and hence differences for a moderately complex set of changes. I suspect you prefer it primarily because you are more used to it or simply because you encountered FC.EXE first. This often happens in all aspects of life. For instance, I speak English and some, limited Norwegian. I find English easier, not because it actually is easier but simply because it was my first language.

Also as others have pointed out, in addition to the various options that let you tweak diff's output there are a wide range of alternative utilities for viewing differences between files. You simply need to do more research.

Thad is correct accidentally! I had no idea they were so far separated in time and wouldn't even have guessed it. But I am sure that it is one of the many utilities that stand alone, and do not exist just because others do.

Actually, I am not a developer, and have only seldom used the "patch" command. However, as a systems manager responsible not only for systems as a whole, but also specifically for various data belonging to various programs, I have often used diff and sdiff so I can say that from my own couple of decades of experience.

Earlier, when speaking about how complex tools are built from basic unix tools, I mentioned FSlint. I thought it was written in shell scripts. I was either thinking of a different tool, or just maybe a different version: it seems to be python. Not correct there!

I was speaking about ls, which is the command which should perform that simple task. In fact, there is a way, and it isBut I new very few people knew this. You would never guess it by reading the man page! But a simple 'DIR /S/AD' will give you all dirs to any depth.

Shell scripting in Unix-like OSs is an arcane language. Because processors are so fast nowadays, everything is done in interpreted languages. So, those scripting languages have end up trying to emulate C. If you want to do fancy, sophisticated things, write a good program and compile it.

F.Y.I. that is exactly the same as my final method the 'magic' is not being done by ls (which is why it is not an example in the man page) but rather by shell expansion. It would be a really odd example to list in the man page.

But shouldn't ls satisfy such an elementary need? On the other hand you can put 'ls -d1 */'. Or add any number of ls options. How do you do this with echo?

No, actually it doesn't has to. The point of Unix/Linux commands is that you can chain them together in the ways you want/need them. So if one tool (in this case the shell) does a job already there is absolutely no need to implement the same functionality again in a different tool (in this case ls). In fact, it is much more sane in this case to let the shell do the job, since this enables any tool to benefit from it, even if it is only a simple echo command.

I actually can't see your point here. So there is tool on DOS/Windows that has a function that you don't have in a tool on *NIX. So what? Use the functionality given to you by your shell or other tools. If you still want to have that specific functionality in that specific tool, no problem at all. It is open source, go ahead and implement it (try that with DOS).

The power of these commands is simply the */ part which is expanded by the shell to match any (non-hidden) file with a name ending with a forward slash and of course only directories will end with a slash. The reason you you would find no reference to this in the ls man page because it is not an ls feature. It is a shell expansion feature, so if it were to be listed as an example anywhere it would be in the expansion section of your shell's man page. Consider also that if you used a shell that did not expand * like this, the command would fail.

By the way the -d is needed in your example because otherwise you would get the contents of the directories, since that is what ls always does by default when you list a direct as an option.

In any case it isn't true that you can use any of the ls options. For example you cannot use -a to show hidden files because ls did not filter them out in the first place. The */ never matched them.

Therefore the 'correct' way to do this (if you really wanted to do it) would be to use either the tree or find examples. They are not dependent on the shell and hence you can continue to use all of their options.

You forgot to answer my question. I'll therefore repeat it for you with highlighting

With tree you could do this as follows

or with find

Now can you do the same with DIR on Windows? Perhaps it is not so simple to do now, due to the limited options on Windows.