Quote:
But when listing nice feature in Windows they do run out fairly quickly. |
Quote:
Code:
man patch The output in the terminal is only human readable to humans who can read English :D ... |
Quote:
Code:
~$ man patch 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. |
Quote:
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! |
Quote:
|
Code:
tree -adL 1 Code:
find . -maxdepth 1 -type d 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? Code:
ls -al | grep ^d Code:
cd [TAB][TAB] Code:
echo */ P.S. You can remove the -a from the tree and ls examples as well if you have no interest in hidden directories. |
Quote:
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 :) |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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! |
Quote:
I was speaking about ls, which is the command which should perform that simple task. In fact, there is a way, and it is Code:
ls -d */ |
Quote:
|
Quote:
|
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). |
Quote:
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. Quote:
Quote:
Code:
tree -adL 3 Code:
find . -maxdepth 3 -type d |
All times are GMT -5. The time now is 05:01 PM. |